Hi
Follow-up for the issue. I stuck with this invalid csum for free
space extent error. Could anyone explain what does it mean? If this
is not data and just a free space, why do we care about its checksum?
And if we do really care then btrfs should have a way to fix this
error. I can fix a file
On Sat, Nov 16, 2013 at 04:06:10AM -0800, Anatol Pomozov wrote:
Hi
Follow-up for the issue. I stuck with this invalid csum for free
space extent error. Could anyone explain what does it mean? If this
is not data and just a free space, why do we care about its checksum?
And if we do really
On Thu, Nov 07, 2013 at 10:56:10PM -0700, Chris Murphy wrote:
What's the kernel and btrfs progs version?
I wish the dmesg errors were more explicit about the nature of checksum
errors: do the two metadata checksums mismatch each other (one of them
matches with data), or the metadata
On Nov 8, 2013, at 1:13 AM, Hugo Mills h...@carfax.org.uk wrote:
On Thu, Nov 07, 2013 at 10:56:10PM -0700, Chris Murphy wrote:
What's the kernel and btrfs progs version?
I wish the dmesg errors were more explicit about the nature of checksum
errors: do the two metadata checksums mismatch
Hi, Frank, thanks for your help again.
Continuing my saga with filesystem recovering.
btrfsck $DEVICE
fails and says some files are corrupted. That is because of my recent
disk crash. I found all these files and indeed - reading it produces
an error. I removed those files and ran btrfsck again.
Hi
I use Linux Arch, kernel 3.11.6.
Recently I had a disk crash and number of my files got corrupted. To
avoid this situation again I added more disks I trying to convert the
data to raid1:
# btrfs balance start -dconvert=raid1 -mconvert=raid1 /
But unfortunately it fails with IO erro. In
Hey Anatol,
I just checked and on my filesystem inode number 362 corresponds to
part of the free space cache. You can check this yourself by running
(as root)
btrfs-debug-tree /dev/sdb | grep (362 -A 3 -B 1
where /dev/sdb is one of the devices from your filesystem.
It printed the following
Hi, Frank
Thanks for your answer.
On Thu, Nov 7, 2013 at 8:41 AM, Frank Holton fhol...@gmail.com wrote:
Hey Anatol,
I just checked and on my filesystem inode number 362 corresponds to
part of the free space cache. You can check this yourself by running
(as root)
btrfs-debug-tree /dev/sdb
Hi
I ran btrfsck hoping that it fix the filesystem so 'balance' would not
crash anymore. But btrfsck itself crashed :(
# btrfsck --repair /dev/sda3
:(
enabling repair mode
Checking filesystem on /dev/sda3
UUID: 25e6a6fa-fe1f-4be5-a638-eeac948f8c21
checking extents
checking fs roots
Hi Anatol,
That certainly does not look good, definitely more than just a bad
space cache. A this point I would strongly suggest that before you try
anything else on the file system that you make sure you have a backup
of everything up there. After you have backed up everything a scrub
may be
What's the kernel and btrfs progs version?
I wish the dmesg errors were more explicit about the nature of checksum errors:
do the two metadata checksums mismatch each other (one of them matches with
data), or the metadata checksums match each other but mismatch with data?
Hopefully I'm
11 matches
Mail list logo
