Dotaz: Vynutit fsck po startu systému.

[lertimir]

Zvolil jsem u openSUSE btrfs jako root file system a po nějaké době vytváří nějaké problémy. např. příkaz less vytvoří zprávu

mktemp: failed to create file via template ‘/tmp/less.XXXXXX’: No space left on device

nicméně podle

df
Filesystem               1K-blocks       Used Available Use% Mounted on
devtmpfs                   4019500         40   4019460   1% /dev
tmpfs                      4036976          0   4036976   0% /dev/shm
tmpfs                      4036976       4508   4032468   1% /run
/dev/dm-1                 20971520   12838376   7588040  63% /

a

 cat /etc/mtab
rootfs / rootfs rw 0 0
devtmpfs /dev devtmpfs rw,relatime,size=4019500k,nr_inodes=1004875,mode=755 0 0
tmpfs /dev/shm tmpfs rw,relatime 0 0

je filesystem rw a je na něm dostatek místa. Podobně se objeví zpráva.

E138: Can't write viminfo file /root/.viminfo!   

pokud jako root něco otevřu vimem a ani soubor neukládám (pokud edituji něco pod uživatelem na /home problém není) Takže to vypadá, jako bych měl root oddíl jen readonly.

ls -l > /test
ls: write error: No space left on device

Jak nemohu mít možnost zapsat do filesystemu, když je na něm přes 7GB místa a je moutnlý read-write?

Nejdříve chci zkusit fsck. Jak bych instruoval systém, že má povinně udělat fsck po restartu? Bootnout live distro je trochu problematické, pokud by problém šel vyřešit přímo na systému bez fyzických změn, dal bych tomu přednost. Co bych ještě mohl zkusit? Nechci vrtat nějakým rozšiřováním oddílu přes gparted dokud nevím v čem je vlastně problém.

Odpovědi

[anonym]

vynuceni fsck se dela zmenou cisel u zaznamu v /etc/fstab, ale pokud tam nedokazes zapsat tak nevim nevim

pokud mas (aspon u ext4, btrfs si nejsem jistej) opravdu hodne malych souboru tak se muze stat ze dojdou inody, syscally pak vetsinou vraci stejnou chybu, takze ti to tvrdi ze neni misto.

zkus "df -i"

dalsi mozna vec jsou snapshoty, nevim jak btrfs pocita misto (bud meri volny a pricita pouzity, takze se hejbe s celkovou veliksoti, nebo naopak "skryte" zabira misto)

[lertimir]

Tak to se budu muset podívat, co dělá s inody btrfs. Příkaz

df -i

pro btrfs filesystem vrací ve všech třech sloupcích 0. A to nejen na tomto problematickém filesystemu, ale i na jiných, které jsou v pořádku. Co se děje se snapshoty zatím nevím, očekával jsem, že když openSUSE nabídne při instalaci možnost použít btrfs jako hlavní systém tak to mají nějak ošéfované, třeba tak, že snapshoty zabírají nějaké rozmné místo a pak se starší mažou.

[Sten]

btrfs alokuje inody dynamicky, takže nemohou dojít. Přehled využití btrfs jde získat pomocí btrfs fi df /.

[JiriHorky]

"nemohou dojit" - to si panove z xfs pred lety taky rikaly a stale se stane, ze sem-tam dojdou, i s inode64 volbou

[Adamec]

ja to resim vytvorenim prazdneho souboru forcefsck na kontrolovanem disku, po restartu se spusti kontrola.

[lertimir]

Do kořenu kontrolovaného disku? Přikaz touch mi prázdný soubor vytváří.

[lertimir]

No dnes už ne.

[Adamec]

jj, kořenu kontrolovaného disku ...ale pokud tam opravdu zapsat nejde, tak asi jedine live usb, ci cd disk ...

[pet]

Btrfs, nastuduj si o nem vic. Zde nebo na root.cz o nem vysel pred par mesici serial. U btrfs je to cele trochu slozitejsi.

[Sten]

1. btrfs nemá fsck (fsck.btrfs bývá symlink na true)
2. df na btrfs nefunguje moc spolehlivě
3. btrfs je tak nové, že bez znalosti verze jádra je těžké říct, co dělat
4. informace, co se děje, bude v dmesg

[lertimir]

No myslel jsem, že fsck.btrfs je už kolem půl roku na světě. A

 ls -l /usr/sbin/fsck*
-rwxr-xr-x 1 root root  30732  7. úno 12.02 /usr/sbin/fsck
-rwxr-xr-x 1 root root  26444 26. led 16.12 /usr/sbin/fsck.btrfs
-rwxr-xr-x 1 root root  13936  7. úno 12.02 /usr/sbin/fsck.cramfs
-rwxr-xr-x 4 root root 250320 15. úno 18.47 /usr/sbin/fsck.ext2
-rwxr-xr-x 4 root root 250320 15. úno 18.47 /usr/sbin/fsck.ext3
-rwxr-xr-x 4 root root 250320 15. úno 18.47 /usr/sbin/fsck.ext4
-rwxr-xr-x 1 root root  30404  7. úno 12.02 /usr/sbin/fsck.minix
lrwxrwxrwx 1 root root      7 14. bře 00.48 /usr/sbin/fsck.msdos -> dosfsck
lrwxrwxrwx 1 root root      7 14. bře 00.48 /usr/sbin/fsck.vfat -> dosfsck

vyhazuje nenulovou velikost existujícího souboru. Právě zprávy o uvolnění fsck na btrfs mě přivedly k rozhodnutí btrfs použít. Jinak distribuce openSUSE 12.3, jádro 3.7.10-1.1-desktop

[Sten]

A dělá to něco? btrfs nemá (tradiční) fsck

Existuje btrfsck, ale to je vhodné tak jedině, pokud nejde to btrfs vůbec namountovat. Jinak by se mělo po mountu opravit samo. Jádro 3.7 je dost nové na to, aby to dělalo.

[lertimir]

Tak se to rozpadá stále více. Včera ještě systém bootnul i když tam byl problém. Pak jsem ho vypnul dnes večer jsem se ho pokusil spustit. Nebootnul, nepřipojil rw root filesystem. na monitoru bylo, že provádí před moutnutím fsck a je uspěšný.

Nicméně zkusil jsem boot s instalačkou openSUSE do recovery modu a další překvapení. pvdisplay, vgdisplay a lvdisplay sice napíšou správné informace group: system a LV root a home, nicméně v /dev/mapper žádné system-root a system-home není a ani není v /dev adresář system s položkami root a home. Nemám oddíl jak připojit. Je možné informace s lvdisplay předat do systému, aby si zařízení vytvořil?

Pokud se mi to nepodaří zdolat do zitra, tak to přeinstaluji. Ale chtěl jsem nejdříve zabojovat a zkusit porozumět a opravit. Naštěstí denní zálohy mám.

[Sten]

LVM lze otevřít pomocí lvchange -ay název_LV

[lertimir]

Přílohy:

• check (120437 bytů)
• dmesg.txt (583 bytů)

Tak jsem se k oddílu již dostal. soubor check je výsledek běhu btrfsck /dev/system/root (redirektován STDOUT i STDERR) a soubor dmesg.txt je výsledek dmesg | tail po pokusu o mount. Vše provedeno s repair bootu z instalačky openSUSE. btrfsck jen vypsal výpis a neopravil data. nasledující běh dopadl stejně a filesystem nešel moutnout. přičemž btrfsck nemá žádné volby.

Zřejmě jsem se unáhlil s přechodem.

[Sten]

Btw. podle toho, jak to postupně umírá, to tipuju na vadný disk. Ale bez dmesg se víc nedozvíme.

[little.owl]

Btw. podle toho, jak to postupně umírá, to tipuju na vadný disk. Ale bez dmesg se víc nedozvíme.

Take me to napadlo. Podobne mne umiral SSD, ale s ext4, doslova se to rozpadalo pod rukama.

[lertimir]

Příloha:

• a.txt (9817 bytů)

Nakonec jsem se rozhodl reinstalovat. Ano. Je možné že ten disk umírá. je to také SSD, a jeden z důvodů, proč jsem zkusil btrfs bylo to že má podporu pro SSD a mělo by k němu chovat jinak než k rotačnímu disku. Jen pro doplnění a uzavření, posílám smartctl -x /dev/sda z toho disku. V hlavní tabulce nemá žádné chyby a celkový zápis je 4000GB za životnost disku, takže to je něco kolem 35 násobného přepsání buňky na 120GB SSD. To by mělo být dost hluboce pod živostností. Hlavně mne překvapila nemožnost opravy toho btrfs. A je zajímavé, že v průběhu instalace openSUSE , kde jedna z možností rozdělení disku je import tabulky to skutečně našlo fstab na tom postiženém disku, takže jsem jen přehodil typ filesystemu na ext a nainstaloval a vše vypadá v pořádku.

jen mám doplňující otázku. Mám filovou zálohu předchozího systému udělanou rsync (backuppc), která je se vším nainstalovaným softem, aktualizacemi asi k předvčerejšku a veškerou konfigurací. mohu si dovolit celý systém s tou zálohou přepsat?

[little.owl]

Podle logu je disk OK, kdyz se to u me sypalo, bylo to videt v tabulce atributu.

Mám filovou zálohu předchozího systému udělanou rsync (backuppc), která je se vším nainstalovaným softem, aktualizacemi asi k předvčerejšku a veškerou konfigurací. mohu si dovolit celý systém s tou zálohou přepsat?

Tady bych byl opatrny, mohlo by to jit, ale backuppc neznam a nevim jake parametry rsync jsou pouzity, jak se to chova k symlinkum ci treba SELinux labelum. Kazdopadne nemate co ztratit, kdyz to zkusite.

[lertimir]

Ještě jeden dotaz. Udělal jsem reinstalaci. Vypadá to, že běžela v pořádku. Po přepsání z systému ze zálohy systém nebootnul. Nenamountoval se kořenový filesystem, protože při bootu si systém myslel, že má kořen na btrfs. I když přesně nevím, co se při startu děje, podezírám, že v initramfs bude informace o tom, že kořen je na btrfs ( a na lvm). Tím pádem neodpovídá situaci a boot padne. Zkusil jsem přegenerovat grub přesgrub2-mkconfig, ale zahlásil mi že nemá /proc/self/moutinfo. (generování jsem provedl tak že jsem s openSUSE DVD šel do recovery modu, anable LV a připojil volume root a boot správně do stromu a provedl chroot do adresáře rootu.) Podobně jsem zkusil vytvořit nový initramfs přes mkinitrd nicméně v Chrootlém prostředí mám /dev (skoro) prázdný

Měl bych otázku, jak bych měl správně opravit initramfs a grub2?

Teď udělám ještě jednu reinstalaci, na tom SSD je to otázka asi 15 minut i z odpovědí na všechny otázky, takže mě to zdrží nejméně, ale rád bych pro příště znal možnost opravy. Díky.

[lertimir]

Tak lepší než reinstalace byla "aktualizace" z distribučního media, která přegenerovala soubory pro boot.

[little.owl]

Podobny problem jsem mel ve kdysi ve Fedore s btrfs a subvolumes, padalo to v grub2-mkconfig, ktery si stezoval ze neni schopen parsovat /proc/self/moutinfo. Zkusil jsem findmnt, ten s tim nemel problem, takze jsem tipoval na bug v grub2. Bohuzel nektere tooly pouzite s kombinaci lvm & btrfs se nezdaji byt moc spolehlive, navic vse je distribucne zavisle.

[Zdeněk Zámečník]

Asi je to zbytečná rada, ale pokud si ceníš dat na tom disku, zálohuj co nejdříve.

Já osobně jsem dával BTRFS několik šancí na desktopu (Linux Mint) i na zálohovacím serveru (Debian Squeeze), ale zrovna minulý týden jsem nad tím definitivně zlomil hůl, alespoň prozatím. Jednou jsem přišel úplně o všechna data a celkem často mi na něm v posledních měsících padal kernel. Zkoušel jsem nad ním provozovat také KVM virtuály a hořce jsem zaplakal, když došlo místo na disku (přestože df říkalo něco jiného) a celé to lehlo. Stále je to filesystém plný dětských nemocí vhodný zatím spíše pro dobrodruhy.

Z vlastní zkušenosti bych řekl, že se chyby začnou projevovat hlavně ve větší zátěži (mnoho častých zápisů, mnoho malých souborů), o to horší překvapení to potom je...

[foldy]

já to dělám takto shutdown -Fr now

[Michal Vyskočil]

openSUSE instaluje snapper, který bohužel ve výchozí konfiguraci dělá každou hodinu snapshot. Podívej se do manuálové stránky snapperu, smaž vše, co v systému máš a potom timeline snapshoty zakaž v konfiguraci snapperu.