Dotaz: Stale file handle

[xorly]

Ahoj, na disku nemohu přistupovat k jednomu souboru. Např. při pokusu o smazání dostanu chybu:

rm: cannot remove 'TerminalBlock_Pheonix_MPT-2.54mm_12pol.wrl': Stale file handle

při výpisu obsahu složky se toho moc nedozvím

...

-????????? ? ? ? ? ? TerminalBlock_Pheonix_MPT-2.54mm_12pol.wrl

...

je to součást jednoho git repozitáře

Hledal jsem na webu a všude tento problém řeší s NFS, to jsem zde nikdy nepoužíval. Provozuji LUKS a v něm mám btrfs. Běžím na ARCHu

Zkusil jsem fsck a scrub celého FS a žádná chyba nebyla nalezena. Narazil jsem na tento thread, ale nakonec to OP vyřešil přeformátováním FS, což se mi moc nechce.

Máte nějaký nápad?

Odpovědi

[NN]

Maznout pres inode nejde?

[xorly]

Právě, že ani inode nedokážu zjistit (ani pod rootem)

# ls -il

...

7332786 -rw-r--r-- 1 xorly users 190338 Feb 29 11:51 TerminalBlock_Pheonix_MPT-2.54mm_12pol.wings

? -????????? ? ? ? ? ? TerminalBlock_Pheonix_MPT-2.54mm_12pol.wrl

7332787 -rw-r--r-- 1 xorly users 29474 Feb 29 11:51 TerminalBlock_Pheonix_MPT-2.54mm_2pol.wings

...

[Jooky (inactive)]

co pise kernel log ? ... ked odmontujes a primontujes fs, tak je to tam stale ?

[xorly]

Z logu jádra jsem grepnul "btrfs", moc tam toho není.

[    2.614280] Btrfs loaded
[    2.614867] BTRFS: device fsid 0751a567-2689-437f-b79a-fd29165da6c6 devid 1 transid 82619 /dev/sdb3
[    2.615466] BTRFS: device fsid fbe3d611-0b48-41a3-9881-6e70e9e3f865 devid 1 transid 1485 /dev/sda2
[    2.615864] BTRFS: device fsid 18009aa7-bd6f-4898-9486-a04bd570ce78 devid 1 transid 626 /dev/sdb4
[    2.639234] BTRFS: device fsid ee483052-1789-480f-941e-99dbf028a36a devid 1 transid 851659 /dev/sda1
[    2.653479] BTRFS info (device sdb3): disk space caching is enabled
[    2.673680] BTRFS: detected SSD devices, enabling SSD mode
[    3.001779] BTRFS info (device sdb3): turning on discard
[    3.001782] BTRFS info (device sdb3): disk space caching is enabled
[    3.934453] BTRFS info (device sda1): enabling auto defrag
[    3.934458] BTRFS info (device sda1): disk space caching is enabled
[    7.607255] BTRFS error (device sda1): could not find root 8
[    7.665622] BTRFS error (device sda1): could not find root 8
[    7.665704] BTRFS error (device sda1): could not find root 8
[   10.934802] BTRFS: device fsid 558daa1c-3f75-42eb-ab4d-7a6fcaea05a1 devid 1 transid 677108 /dev/dm-0
[   10.960745] BTRFS info (device dm-0): enabling auto defrag
[   10.960754] BTRFS info (device dm-0): disk space caching is enabled
[   14.479638] BTRFS info (device sdb4): use ssd allocation scheme
[   14.479653] BTRFS info (device sdb4): turning on discard
[   14.479658] BTRFS info (device sdb4): disk space caching is enabled
[   14.479662] BTRFS: has skinny extents

Jedná se o dm-0, normální HDD. (sda1 mám na /var) Umount/mount se děje při každém vypnutí/zapnutí systému a nebyl s tím žádný problém. Jinak beze změny.

[Sten]

btrfs scrub start -B /

Řekne to víc informací a zkusí opravit to, co bezpečně jde.

[xorly]

# btrfs scrub start -B /home
scrub done for 558daa1c-3f75-42eb-ab4d-7a6fcaea05a1
	scrub started at Sun Mar 13 11:07:05 2016 and finished after 00:49:27
	total bytes scrubbed: 290.08GiB with 0 errors

a RAW výstup

scrub status for 558daa1c-3f75-42eb-ab4d-7a6fcaea05a1
scrub device /dev/mapper/home (id 1) history
        scrub started at Sun Mar 13 11:07:05 2016 and finished after 00:49:27
        data_extents_scrubbed: 5358723
        tree_extents_scrubbed: 276588
        data_bytes_scrubbed: 306945388544
        tree_bytes_scrubbed: 4531617792
        read_errors: 0
        csum_errors: 0
        verify_errors: 0
        no_csum: 1178308
        csum_discards: 0
        super_errors: 0
        malloc_errors: 0
        uncorrectable_errors: 0
        unverified_errors: 0
        corrected_errors: 0
        last_physical: 467115442176

Právě, že žádnou chybu nenajde...

[Jooky (inactive)]

Este pre kontrolu ... nebol v minulosti ten fs nekorektne odpojeny ? ... strata napajania, problem s diskom, kernel panic, etc. ...

[xorly]

Párkrát jsem omylem vycucnul baterku v NB na nulu. Takže powerloss určitě nastal... S Diskem žádné problémy nejsou ani nebyly. Ve SMART jsou nenulové jen provozní parametry jako spinup time, teplota apod., žádné chyby.

Párkrát jsem v minulosti kernel panic na tomhle stroji měl a to dokonce něco kvůli btrfs. Avšak v Archu vychází jádro dost často a problém byl rychle pryč. Nicméně se to určitě stalo dříve něž tento soubor vůbec vzniknul.

[Jooky (inactive)]

Ja som presne narazal na ten bug, co spomenul "lertimir" dole ... problem je, ze ak niecomu takemu doslo, tak medatada checksumy su "vporiadku" a teda klasicky scrub s tym nic nezpravi. Skusal si zbehnut check (nie fsck) ? ... ten kontroluje aj logicku integritu, takze je sanca, ze by to mohol opravit (je dobre mat latest btrfs tooly) ...

[xorly]

Tady je výstup btrfs check. Moc mi to neříká.

# btrfs check -p --check-data-csum  /dev/mapper/home
Checking filesystem on /dev/mapper/home
UUID: 558daa1c-3f75-42eb-ab4d-7a6fcaea05a1
checking extents [o]
checking free space cache [o]
checking fs roots [o]
found 309216416127 bytes used err is 0
total csum bytes: 295143188
total tree bytes: 2262269952
total fs tree bytes: 1834450944
total extent tree bytes: 82804736
btree space waste bytes: 357692599
file data blocks allocated: 309234204672
 referenced 302608572416

[Sten]

Nekorektní odpojení by nemělo vadit žádnému modernímu souborovému systému

[Jooky (inactive)]

Nemalo, ale bohuzial bol tam bug ... tak isto napr aj ext4 mal niekedy dost zly bug co sa tyka log replay ... vid komentar od "lertimir" nizsie

[Sten]

Zvláštní, že to nenašlo žádnou chybu, ten podivný soubor má tedy platný checksum metadat. Zkusil bych ještě btrfs check /, ten to zkoumá víc do detailů.

[lertimir]

Případ řeší v patchích.

[PATCH] Btrfs: fix stale directory entries after fsync log replay

[PATCH v3] Btrfs: fix metadata inconsistencies after directory fsync

[Bug 942925] btrfs: multiple cases where fsync can corrupt inode link counts

Ale podrobně jsem je neprocházel.

[xorly]

Díky, co jsem se dohledal, tak patche se dostaly do jádra už někdy v září 2015. U mě problém nenastal víc jak 2 měsíce zpět. Možná je to nějaký další bug.