/tmp problem
27 отговора
927 прегледа
Независимо от съдържанието,
можеш да направиш файлова система във файл. Нещо повече - това е задължително, преди да монтираш файла. Пример:
dd if=/dev/zero of=loopback.fs bs=1024 count=1024
mkreiserfs loopback.fs
mount -o loop loopback.fs /mnt/mount-point
dd if=/dev/zero of=loopback.fs bs=1024 count=1024
mkreiserfs loopback.fs
mount -o loop loopback.fs /mnt/mount-point
Може би защото е опасно
Непосредствено след зареждането на ядрото е монтирана само файловата система /. За да може да продължи зареждането по-нататък трябва във файловата система на / да се намират поне директориите etc, bin и sbin. /usr и /home, от друга страна, съвсем спокойно могат да са в друга файлова система, че дори и на друг компютър - не е толкова страшно; ако нещо не стане монтирането им, разполагайки с необходимия минимум инструменти в /bin и /sbin имаш възможност от конзолата като root да поправиш нещата.
Сега, ако имаш отделна файлова система за /tmp и по някаква причина тя не се монтира, почти сигурен съм че нещата доста ще се скапят. Защото немалко програми разчитат на съществуването на /tmp за работата си и просто няма да работят ако тази директория липсва. Разбира се, можеш да си направиш tmp във файловата система на / и после да монтираш "истинската" /tmp, като използваш първоначалната tmp само като резерв, но все пак това почва да прилича на висш пилотаж, а дистрибуциите като правило се ориентират към надеждно инсталиране, а не към автоматично използване на ресурсите на мах.
В моята дистрибуция, например (OpenLinux), се счита, че ако знаеш какво правиш, можеш да си нащракаш директориите и в кои дялове стоят те в началото с custom setup, след което инсталацията минава и създава необходимите записи в /etc/fstab. 99.(9)% съм сигурен, че и в RedHat е така, както и в другите масови дистрибуции. Но ако не си сигурен, по-добре е целият ти Linux да стои в един дял, поне докато не се научиш кое как е, след което можеш да си настроиш системата както си искаш.
Решението ти не е никак лошо. А самото създаване на дял също не е никак трудно, ако не си запълнил всички места за дялове в MBR и имаш свободно място на диска. Опитай, и ако не стане - свиркай, ще помагаме.
Сега, ако имаш отделна файлова система за /tmp и по някаква причина тя не се монтира, почти сигурен съм че нещата доста ще се скапят. Защото немалко програми разчитат на съществуването на /tmp за работата си и просто няма да работят ако тази директория липсва. Разбира се, можеш да си направиш tmp във файловата система на / и после да монтираш "истинската" /tmp, като използваш първоначалната tmp само като резерв, но все пак това почва да прилича на висш пилотаж, а дистрибуциите като правило се ориентират към надеждно инсталиране, а не към автоматично използване на ресурсите на мах.
В моята дистрибуция, например (OpenLinux), се счита, че ако знаеш какво правиш, можеш да си нащракаш директориите и в кои дялове стоят те в началото с custom setup, след което инсталацията минава и създава необходимите записи в /etc/fstab. 99.(9)% съм сигурен, че и в RedHat е така, както и в другите масови дистрибуции. Но ако не си сигурен, по-добре е целият ти Linux да стои в един дял, поне докато не се научиш кое как е, след което можеш да си настроиш системата както си искаш.
Решението ти не е никак лошо. А самото създаване на дял също не е никак трудно, ако не си запълнил всички места за дялове в MBR и имаш свободно място на диска. Опитай, и ако не стане - свиркай, ще помагаме.
нещо за resize на партишън?
което работи под linux? Иска ми се да си намаля /home и да си увелича root-a.
Със PartitionMagic сигурно ще стане, но ми се иска да го направя с linux-a. Идеята разбира се е да го направя без загуба на данни. tnx предварително за помоща. Благодаря и за изчерпателната информация относно /tmp.
Със PartitionMagic сигурно ще стане, но ми се иска да го направя с linux-a. Идеята разбира се е да го направя без загуба на данни. tnx предварително за помоща. Благодаря и за изчерпателната информация относно /tmp.
Re: нещо за resize на партишън?
GNU ext2resize is a package which allows resizing ext2 filesystems (both shrinking and growing).
[линк]
[линк]
Re: No comment!
niama nikakwo znachenie s kakwo e pylen file-a. sled kato napravish fs na nego toi weche e pylen sys savsem drugi neshta :)
i izobshto ne e dobra idea da napravish file sys "dupki", da napravish fs na nego i da go montirash. ako napravish fs na "dupchest" file 300MB, niama garancia che file-a realno shte gi zaeme tezi 300MB na roditelskata fs. i kato napylnish roditelskata fs moje da se okaje che ne mojesh da zapishesh i 10MB w 300MB-ovia file. Towa e samo wild guess -- ne znam dali mkfs ne se podsiguriava file-a da e bez dupki (intuiciata mi podskazwa che ne)
i izobshto ne e dobra idea da napravish file sys "dupki", da napravish fs na nego i da go montirash. ako napravish fs na "dupchest" file 300MB, niama garancia che file-a realno shte gi zaeme tezi 300MB na roditelskata fs. i kato napylnish roditelskata fs moje da se okaje che ne mojesh da zapishesh i 10MB w 300MB-ovia file. Towa e samo wild guess -- ne znam dali mkfs ne se podsiguriava file-a da e bez dupki (intuiciata mi podskazwa che ne)
Занчи...
аз съм правил 100MB файл...
това значи ли, че може нещо да се скапе при по-голям такъв?
Самата идея винаги ми е допадала - от един файл правя нов дял:)
Човек винаги се учи, ще направя файл с единици....

това значи ли, че може нещо да се скапе при по-голям такъв?
Самата идея винаги ми е допадала - от един файл правя нов дял:)
Човек винаги се учи, ще направя файл с единици....
Ще
В момента на създаването на файловата система във файл, този файл вече е изял (в твоя пример) 300 MB на диска и не виждам причини да не може да се използва, след като файловата система се напълни. Това е все едно да кажеш, че дяла на Linux няма да може да се използва, ако цялата останала част на диска се разпредели в дялове.
От гледна точка на файловата система, нещото, в което тя е създадена, представлява еди-колко си последователни блока, в които може да се разпростира както пожелае. След като всички блокове се заемат, файловата система е пълна. Но самите блокове трябва да са нейни (на файловата система) още при създаването й, при това всичките до един - нито повече, нито по-малко.
Всъщност, това което казваш, може да се случи на по-особените (не ми идва по-добра дума) файлови системи, в които размера на блоковете е плаващ - например компресирана файлова система, или в случай, че алокирането на 300 MB за файл не означава наистина заделени специално и само за този файл 300 MB на диска. Не знам за Linux да има такова животно, но бях чел, че Microsoft имат някакви си файлове в Win2k, които можеш да ги направиш ако щеш терабайт на размер, но на диска се пазели само тези части от файла, в които има данни.
От гледна точка на файловата система, нещото, в което тя е създадена, представлява еди-колко си последователни блока, в които може да се разпростира както пожелае. След като всички блокове се заемат, файловата система е пълна. Но самите блокове трябва да са нейни (на файловата система) още при създаването й, при това всичките до един - нито повече, нито по-малко.
Всъщност, това което казваш, може да се случи на по-особените (не ми идва по-добра дума) файлови системи, в които размера на блоковете е плаващ - например компресирана файлова система, или в случай, че алокирането на 300 MB за файл не означава наистина заделени специално и само за този файл 300 MB на диска. Не знам за Linux да има такова животно, но бях чел, че Microsoft имат някакви си файлове в Win2k, които можеш да ги направиш ако щеш терабайт на размер, но на диска се пазели само тези части от файла, в които има данни.
Re: Ще
Osogovetz spomena che null i zero za nego bili razlichni neshta. File-a e
poredica ot baitove. w baita kakto wsichki znaem stoinostite sa ot 0 do 255.
Null niama. Edinstvenia nachin na opredelena pozicia wyw file da ima neshto
razlichno ot stoinostite 0-255 e ako file-a e s dupka. zatowa reshih che
toi gowori za syzdavane na fs v/u file s dupki.
Ochevidno ne wsichki tuk sa chuvali za files s dupki, zatowa shte napravia
lirichno otklonenie ...
Powecheto osnovni fs na Unix pozwoliavat syzdavane na file-ove s dupki. Primer
valinor:~# df
Filesystem 1k-blocks Used Available Use% Mounted on
/dev/hda3 4032124 3833048 158112 97% /
/dev/hda6 4449296 4386152 63144 99% /mnt/misc
none 95768 0 95768 0% /dev/shm
valinor:~# dd if=/dev/zero of=test seek=1000000 count=2
2+0 records in
2+0 records out
valinor:~# ls -l test
-rw-r--r-- 1 root root 512001024 Mar 1 08:29 test
valinor:~# du -k test
12 test
valinor:~# df
Filesystem 1k-blocks Used Available Use% Mounted on
/dev/hda3 4032124 3833060 158100 97% /
/dev/hda6 4449296 4386152 63144 99% /mnt/misc
none 95768 0 95768 0% /dev/shm
Na filesystem s 158M free, syzdadoh file s razmer 512M. Realno toi
polzwa ot diska 12K.
Ako niakoi opita da chete stoinosti ot file-a koito se namirat w dupkata,
shte poluchi nuli.
Da se wyrnem na sluchaia kogato se opitvame da napravim fs na takyv file.
valinor:~# /sbin/mke2fs test
mke2fs 1.23, 15-Aug-2001 for EXT2 FS 0.5b, 95/08/09
test is not a block special device.
Proceed anyway? (y,n) y
warning: 288 blocks unused.
Filesystem label=
OS type: Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
125416 inodes, 499713 blocks
25000 blocks (5.00%) reserved for the super user
First data block=1
61 block groups
8192 blocks per group, 8192 fragments per group
2056 inodes per group
Superblock backups stored on blocks:
8193, 24577, 40961, 57345, 73729, 204801, 221185, 401409
Writing inode tables: done
Writing superblocks and filesystem accounting information: done
This filesystem will be automatically checked every 21 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.
valinor:~#
Ako proverim kolko miasto zaema file-a sega:
valinor:~# du -k test
16684 test
Montirame failovata sistema ...
valinor:~# mount -o loop test /mnt/cdrom
valinor:~# df
Filesystem 1k-blocks Used Available Use% Mounted on
/dev/hda3 4032124 3849732 141428 97% /
/dev/hda6 4449296 4386152 63144 99% /mnt/misc
none 95768 0 95768 0% /dev/shm
/root/test 483886 13 458873 1% /mnt/cdrom
Oops, kernel-a si misli che razpolaga s 458M na fs /root/test
Neka se opitame da zapishem tam file 350M -- shtom imame tolkowa mnogo
miasto ...
valinor:~$ dd if=/dev/zero of=/mnt/cdrom/test1 count=700000
dd zapochwa da pishe po diska ... ot druga console-a sled 5 min "pisane"
valinor:~$ df
Filesystem 1k-blocks Used Available Use% Mounted on
/dev/hda3 4032124 4032124 0 100% /
/dev/hda6 4449296 4386152 63144 99% /mnt/misc
none 95768 0 95768 0% /dev/shm
/root/test 483886 189896 268990 42% /mnt/cdrom
w prodyljenie na oshte 5 min df ne pokazwa nikakwa promiana (wypreki che
diska pokazwa aktivnost) i reshavam da spra dd.
valinor:~$ dd if=/dev/zero of=/mnt/cdrom/test1 count=700000
268537+0 records in
268536+0 records out
valinor:~$ ls -l /mnt/cdrom/test1
-rw-r--r-- 1 lucho lucho 137490944 Mar 1 08:46 /mnt/cdrom/test1
znachi ne samo ne sme namerili magichen nachin da zapisvame 350M files na 150M
file system, no i sme uspeli da nakarame kernel-a da se "zacikli", davaiki
falshiva nadejda na process-a koito se opitva da pishe w loopback fs che wse
niakoga shte uspee da zapishe 350-te M koito mu e obeshtal ...
opita mi da zapisha 350MB-ovia file kato obiknoven user ne e sluchaen.
Rezultata e syshtia ako optita se napravi i kato root. Iskam da pokaja oshte
edna nepriatnost s "dupchestite" files s loopback fs. Ako poglednete
rezultatite ot pyrvia df, available sa 158112 blocks, po-malko otkolkoto
realno ima svobodni (zaradi reserviranite za root blocks). Kato zapochnem da
pishem kato obiknoven user v/u /root/test fs, zabeliazwame ot poslednia df
che sme uspeli da zaemem _wsichkite_ 199064 free blocks na /. Ot gledna
tochka na kernel-a towa e pravilno.
Smiatam che sega uspiah da raziasnia kakwo iskah da kaja s po-malko dumi w
prednia msg. Lichno az smiatah che kernel-a shte dade greshka wmesto da zacikli ...
poredica ot baitove. w baita kakto wsichki znaem stoinostite sa ot 0 do 255.
Null niama. Edinstvenia nachin na opredelena pozicia wyw file da ima neshto
razlichno ot stoinostite 0-255 e ako file-a e s dupka. zatowa reshih che
toi gowori za syzdavane na fs v/u file s dupki.
Ochevidno ne wsichki tuk sa chuvali za files s dupki, zatowa shte napravia
lirichno otklonenie ...
Powecheto osnovni fs na Unix pozwoliavat syzdavane na file-ove s dupki. Primer
valinor:~# df
Filesystem 1k-blocks Used Available Use% Mounted on
/dev/hda3 4032124 3833048 158112 97% /
/dev/hda6 4449296 4386152 63144 99% /mnt/misc
none 95768 0 95768 0% /dev/shm
valinor:~# dd if=/dev/zero of=test seek=1000000 count=2
2+0 records in
2+0 records out
valinor:~# ls -l test
-rw-r--r-- 1 root root 512001024 Mar 1 08:29 test
valinor:~# du -k test
12 test
valinor:~# df
Filesystem 1k-blocks Used Available Use% Mounted on
/dev/hda3 4032124 3833060 158100 97% /
/dev/hda6 4449296 4386152 63144 99% /mnt/misc
none 95768 0 95768 0% /dev/shm
Na filesystem s 158M free, syzdadoh file s razmer 512M. Realno toi
polzwa ot diska 12K.
Ako niakoi opita da chete stoinosti ot file-a koito se namirat w dupkata,
shte poluchi nuli.
Da se wyrnem na sluchaia kogato se opitvame da napravim fs na takyv file.
valinor:~# /sbin/mke2fs test
mke2fs 1.23, 15-Aug-2001 for EXT2 FS 0.5b, 95/08/09
test is not a block special device.
Proceed anyway? (y,n) y
warning: 288 blocks unused.
Filesystem label=
OS type: Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
125416 inodes, 499713 blocks
25000 blocks (5.00%) reserved for the super user
First data block=1
61 block groups
8192 blocks per group, 8192 fragments per group
2056 inodes per group
Superblock backups stored on blocks:
8193, 24577, 40961, 57345, 73729, 204801, 221185, 401409
Writing inode tables: done
Writing superblocks and filesystem accounting information: done
This filesystem will be automatically checked every 21 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.
valinor:~#
Ako proverim kolko miasto zaema file-a sega:
valinor:~# du -k test
16684 test
Montirame failovata sistema ...
valinor:~# mount -o loop test /mnt/cdrom
valinor:~# df
Filesystem 1k-blocks Used Available Use% Mounted on
/dev/hda3 4032124 3849732 141428 97% /
/dev/hda6 4449296 4386152 63144 99% /mnt/misc
none 95768 0 95768 0% /dev/shm
/root/test 483886 13 458873 1% /mnt/cdrom
Oops, kernel-a si misli che razpolaga s 458M na fs /root/test
Neka se opitame da zapishem tam file 350M -- shtom imame tolkowa mnogo
miasto ...
valinor:~$ dd if=/dev/zero of=/mnt/cdrom/test1 count=700000
dd zapochwa da pishe po diska ... ot druga console-a sled 5 min "pisane"
valinor:~$ df
Filesystem 1k-blocks Used Available Use% Mounted on
/dev/hda3 4032124 4032124 0 100% /
/dev/hda6 4449296 4386152 63144 99% /mnt/misc
none 95768 0 95768 0% /dev/shm
/root/test 483886 189896 268990 42% /mnt/cdrom
w prodyljenie na oshte 5 min df ne pokazwa nikakwa promiana (wypreki che
diska pokazwa aktivnost) i reshavam da spra dd.
valinor:~$ dd if=/dev/zero of=/mnt/cdrom/test1 count=700000
268537+0 records in
268536+0 records out
valinor:~$ ls -l /mnt/cdrom/test1
-rw-r--r-- 1 lucho lucho 137490944 Mar 1 08:46 /mnt/cdrom/test1
znachi ne samo ne sme namerili magichen nachin da zapisvame 350M files na 150M
file system, no i sme uspeli da nakarame kernel-a da se "zacikli", davaiki
falshiva nadejda na process-a koito se opitva da pishe w loopback fs che wse
niakoga shte uspee da zapishe 350-te M koito mu e obeshtal ...
opita mi da zapisha 350MB-ovia file kato obiknoven user ne e sluchaen.
Rezultata e syshtia ako optita se napravi i kato root. Iskam da pokaja oshte
edna nepriatnost s "dupchestite" files s loopback fs. Ako poglednete
rezultatite ot pyrvia df, available sa 158112 blocks, po-malko otkolkoto
realno ima svobodni (zaradi reserviranite za root blocks). Kato zapochnem da
pishem kato obiknoven user v/u /root/test fs, zabeliazwame ot poslednia df
che sme uspeli da zaemem _wsichkite_ 199064 free blocks na /. Ot gledna
tochka na kernel-a towa e pravilno.
Smiatam che sega uspiah da raziasnia kakwo iskah da kaja s po-malko dumi w
prednia msg. Lichno az smiatah che kernel-a shte dade greshka wmesto da zacikli ...