Marc MERLIN wrote on 2016/02/11 07:13 -0800:
On Thu, Feb 11, 2016 at 07:09:47AM -0800, Marc MERLIN wrote:
On Thu, Feb 11, 2016 at 03:16:47PM +0800, Qu Wenruo wrote:
I started making a dump, image was growing past 3GB, and then it failed
and the image got deleted:
gargamel:~# btrfs-image -s -c 9 /dev/mapper/dshelf1old /mnt/dshelf1/ds1old.dump
Error adding space cache blocks -5
It seems that btrfs-image failed to read space cache, in
read_data_extent() function.
And since there is no "Couldn't map the block XXXX" error message,
either some device is missing or pread64 failed to read the desired
data.
It's a 5 drive raid5 underneath, all drives are there.
Is there a 4G file size limit, or did I hit another problem?
For the 4G file size limit, did you mean the limit from old
filesystem like FAT32?
No, I wrote on btrfs, so it's not a filesystem limit, but I meant that
maybe if there was a 32bit pointer somewhere, it could have caused this.
I did use the 64bit version of the tools on a 64bit kernel though, so I
don't see why it could have happened.
I didn't think there is such limit for modern Linux filesystem, or
normal read/write operation won't has such limit either.
Agreed.
At this point, is there anything else I should get/do before I wipe this
filesystem?
There is still a last chance.
If btrfsck still report original error about "bad file extent" in root:
45851/45852/...
Btrfs-debug-tree may provide useful info by dumping only that root.
# btrfs-debug-tree -t 45851
But the problem is, there is no filename fuzz option.
You need to mask all the filenames in INODE_REF/DIR_ITEM/DIR_INDEX by
script, or just grep the affected inode info following the pattern "key
(<INODE_NUM>".
At least this should tell us what's the problem and we can check
manually to determine if it's fixable.
And I just remember that, if you only need to get a clean fs without
fsck warning, trying removing all affected subvolumes is possible idea.
Thanks,
Qu
I should note that I can mount it fine and read/write to it.
I also ran fsck check --repair on it more than once.
Marc
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
