elysium-planitia:/tmp # df -h Filesystem Size Used Avail Use% Mounted on ... /dev/sda1 20G 17G 3.6G 83% / ... elysium-planitia:/tmp # rm -rf * elysium-planitia:/tmp # df -h Filesystem Size Used Avail Use% Mounted on ... /dev/sda1 20G 20G 630M 97% / ... elysium-planitia:/tmp # sync elysium-planitia:/tmp # df -h Filesystem Size Used Avail Use% Mounted on ... /dev/sda1 20G 16G 3.9G 81% / ...
- lajos22 blogja
- A hozzászóláshoz be kell jelentkezni
- 1019 megtekintés
Hozzászólások
Hogy ezt mindig elfelejtem...
--
openSUSE 42.1 x86_64
- A hozzászóláshoz be kell jelentkezni
Szep uj vilag amikor minden uj fajlrendszer az egysegesitesre torekves helyett eljatsza majd, hogy fejlesszunk uj "df/akarmilyen toolt"-et nehogymar egy rajtunk kivulallo meg tudja mondani mennyi szabad hely van rajtam/el tudjon vegezni egy feladatot rajtam...
- A hozzászóláshoz be kell jelentkezni
Nem az új fájlrendszerekkel van a baj, sokkal inkább a régi eszközökkel, amik nem tartják a lépést.
Ha a régi eszköz egy adatot tud visszaadni, hogy mennyi a szabad hely, de az új fájlrendszeren már több értelmezése is van a szabad hely fogalmának, akkor mit kellene a régi eszköz felé visszaadnia? Ha az egyiket adja vissza az a baj, ha a másikat, akkor meg az.
Egyébként a BTRFS fejlesztők kérik a segítséget, hogy aki tud az adjon egy jó ötletet, hogy milyen értéket adjanak vissza szabad helyként.
"So, in general, it is impossible to give an accurate estimate of the amount of free space on any btrfs filesystem. Yes, this sucks. If you have a really good idea for how to make it simple for users to understand how much space they've got left, please do let us know, but also please be aware that the finest minds in btrfs development have been thinking about this problem for at least a couple of years, and we haven't found a simple solution yet. "
Ne hozzanak létre jobb fájlrendszereket, mert a régi eszközök nem teljesen kompatibilisek velük?
(A ZFS-nél is hasonló a helyzet)
- A hozzászóláshoz be kell jelentkezni
zfsnel mukodik df :)
- A hozzászóláshoz be kell jelentkezni
Btrfs-nél is hasonlóan működik :-)
- A hozzászóláshoz be kell jelentkezni
Nalam zfsel mindig jot ir. btrfsel meg egy fos :)
- A hozzászóláshoz be kell jelentkezni
"Egyébként a BTRFS fejlesztők kérik a segítséget, hogy aki tud az adjon egy jó ötletet, hogy milyen értéket adjanak vissza szabad helyként."
Esetleg egy összesítés?
--
openSUSE 42.1 x86_64
- A hozzászóláshoz be kell jelentkezni
Ez az "impossible" dolog inkabb tervezesi hianyossag. Mi az, hogy nem lehet megmondani mennyi szabad hely van a fajlrendszeren ?
Engem ha egy "df / " kimenete erdekel az erdekel, hogy a / fajlrendszeren mennyi szabad hely van. Hidegen hagy, hogy mennyi metadata van szabadon. Hidegen hagy egy subvolume szabad helye.
Olyan nehez ezt megoldani ?
Szamomra inkabb a "nem akarasnak nyoges a vege" szolasra hajaz ...
- A hozzászóláshoz be kell jelentkezni
"Olyan nehez ezt megoldani ?"
Nem, meg is mondja, csak kérdés, hogy azzal mire mész.
Pl. ha be van kapcsolva a tömörítés és azt írja, hogy a szabad terület 100MB, de simán írhatsz oda 200MB szövegfájlt és még mindig lesz szabad helyed.
Vagy azt írja, hogy 10G-ból 5G szabad hely van, törölsz mindent és még mindig 5G a szabd hely, mert van snapshot-od, amit nem látsz.
Raid-nél megint csak vannak trükkök.
Egyébként, ha nem használsz semmi új feature-t, akkor a df kb. a máshol is megszokott szabad helyet mutatja.
- A hozzászóláshoz be kell jelentkezni
Olyan, nincs hogy valamit nem lehet megoldani. Olyan van, hogy bad design meg balfasz fejlesztok.
- A hozzászóláshoz be kell jelentkezni
Amit meg hozzatennek:
Sajat szemelyes velemenyem, hogy az Open Source fejlesztok nem latjak a fatol az erdot. Nem attol lesz egy termek sikeres ha allandoan megvaltoztatjuk a felhasznalo interface-t. Legyen az akar egy GUI vagy egy parancs kimenete. Ha ellenben reklamalni mer barki is, hogy miert kellett egy tizensokeve ugyanugy visszatero kimenetet megvaltoztatni (ami utanna minden script/alkalmazas ujrarirasaval jar) akkor csak hummoges vagy oltari lebaszas jon vissza, hogy mire fel mered te kritizalni.
Hasonlot erzek en itt is. Hatalmas az utalas minden fele ami zart forrasu. Viszont a nyilt forras vilagaban pedig pontosan az hianyzik ami a zartnal megvan: kontroll. Minden fejleszto csapat (btrfs, kernel reszlegek, lib, ui etc) mennek a sajat fejuk utan. Az mar mas kerdes, hogy emellett dokumentalni is olyan minosegben tesznek, hogy neha ember legyen a talpan aki rajon, hogy egy project adott verzioja eseten mi a helyes kulcsszo es parameterek.
Nem azt mondom, hogy a zart forras tokeletes es minden esetben jo viszont az open source vilag jelenleg inkabb kaoszt teremt mint rendet...
- A hozzászóláshoz be kell jelentkezni
+1
Teljeskörűen leírtad a problémát. Csak annyival egészíteném ki, hogy lehet ezt rövidebben is. ;)
Mindazok az alapszintű elemek, amelyek nem részei az operációs rendszernek, és/vagy nem dokumentáltak, és/vagy inkonzisztesek a rendszer szemponjából, azok a játékprogram kategóriába sorolandók, tehát nem valók production környezetbe.
A zárt forrás nem egyértelmű kritérium, de a gyakorlatban igaz, hogy a linux lassacskán lekörözi a Windows-származékokat. ;)
- A hozzászóláshoz be kell jelentkezni