Opened 4 years ago

Last modified 3 years ago

#12698 new bug

Strange checkfs behavior

Reported by: X512 Owned by: axeld
Priority: normal Milestone: R1
Component: System/Kernel Version: R1/Development
Keywords: checkfs cache Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All

Description

This is hrev50152.

When running checkfs -c sometimes I get inconsistent results such as different count of checked nodes, blocks that could be freed and others. Also sometimes checkfs reports that some random files that "could not be opened". List of files that could not be opened is different after each call of checkfs -c and sometimes empty. In theory checkfs -c should not change anything, but check results of consecutive checkfs -c calls are different. When checkfs returns inconsistent results, consecutive calls are not fast as usual (for example usually second call of checkfs can be done for about 3 seconds while first was about 10 minutes, node count is about 300000). Running checkfs from boot usb immidiately after boot don't cause this issue.

This is probably caused by error in disk block caching for reading.

Sample checkfs result:

> checkfs -c /boot
haiku_unsupported-nightly-hrev50163-x86_hybrid-raw (inode = 6815673), could not be opened
        259418 nodes checked,
        0 blocks not allocated,
        0 blocks already set,
        307218 blocks could be freed

        files           235130
        directories     23178
        attributes      704
        attr. dirs      366
        indices         40

        direct block runs               255611 (40.90 GiB)
        indirect block runs             809 (in 44 array blocks, 15.78 GiB)
        double indirect block runs      0 (in 0 array blocks, 0 バイト)

checkfs result from live USB:

> checkfs -c /Haiku1
        259416 nodes checked,
        0 blocks not allocated,
        0 blocks already set,
        7 blocks could be freed

        files           235128
        directories     23178
        attributes      704
        attr. dirs      366
        indices         40

        direct block runs               255600 (41.38 GiB)
        indirect block runs             798 (in 41 array blocks, 15.30 GiB)
        double indirect block runs      0 (in 0 array blocks, 0 バイト)

Note "blocks could be freed" value.

Change History (5)

comment:1 by X512, 4 years ago

Running checkfs without "-c" can be dangerous because it can mark used blocks as free and allocate data in already used blocks causing data corruption.

comment:2 by pulkomandy, 3 years ago

Is this on a partition mounted read-only? Since checkfs works without unmounting the partition, it could simply be regular filesystem activity going on while it runs.

Can you reproduce this on a read-only volume as well?

The second and following calls being faster can be explained by everything (or almost) being cached to RAM by the first run.

comment:3 by X512, 3 years ago

Partition was not mount read only because it was boot partition when issue happens. But I didn't write anything between checks. When I tried to check same partition from live USB no errors except 7 block that could be freed. Also result was consistent.

Issue seems to be often reproducible.

comment:4 by X512, 3 years ago

Is it possible to completely disable disk cache?

comment:5 by axeld, 3 years ago

The disk cache cannot be disabled. With "from live USB" you mean that you've booted Haiku from USB? Without further info, I would assume that the actual cause is memory or rather, the lack of it, ie. I'd assume that this is a duplicate of #10312.

Can you still reproduce it? And if you can, can you please provide a syslog?

Note: See TracTickets for help on using tickets.