Hendrik Friedel <hendrik@xxxxxxxxxxxxx> schrieb: > I re-post this: > [...] >> root 256 inode 9579 errors 100 >> root 256 inode 9580 errors 100 >> root 256 inode 14258 errors 100 >> root 256 inode 14259 errors 100 >> root 4444 inode 9579 errors 100 >> root 4444 inode 9580 errors 100 >> root 4444 inode 14258 errors 100 >> root 4444 inode 14259 errors 100 >> found 2895817096773 bytes used err is 1 100 is I_ERR_FILE_EXTENT_DISCOUNT. I'm not sure what kind of problem this indicates but btrfsck does not seem to fix this currently - it just detects it. I'm living with errors 400 (I_ERR_FILE_NBYTES_WRONG) and 2000 (I_ERR_LINK_COUNT_WRONG) and had no problem with that yet. I suppose you can simply ignore it for the time being, ensure you have a working backup and hope the kernel handles it well when it encounters such "broken" inodes. And from what I've read in the past btrfs is designed to handle and fix most errors on the fly from within the kernel. So it may just "fix" it when such an inode is modified. Thus, btrfsck is meant just as a tool to fix errors that can't be handled in kernel space. I may be wrong however, experts on the list could give a more detailed insight. BTW, my first impression was that "errors 400" means something like "400 errors" - but that is just a hex bitmask which shows what errors have been found. So "errors 100" is just _one_ bit set, thus only _one_ error. You can use "btrfs subvolume list" to identify which subvolume 4444 is and maybe recreate it or just delete it if it is disposable. The errors should be gone then. That won't work for subvolume 256, however, for it being the root subvolume obviously. The last of the quoted errors, by pure guessing, probably indicates a problem with the space cache. But I think you already tried discarding it. Did you run btrfsck right after discarding it without regenerating the space cache? Does it still show that error then? Regards, Kai -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
