On 11 Jul 2010, at 17:43, Chris Mason wrote:
> Was this after a fresh mkfs? Clearly things are very corrupt on this
> original drive. It would be a good test case for Yan Zhengs new fsck
> code, but first I'd like to figure out if you're still seeing the old
> corruption of if you've started ove
On Wed, Jul 07, 2010 at 10:39:48PM -0400, Daniel Kozlowski wrote:
> >> Looks like we're looping on a single block. What happens when you
> >> dmesg -n1 to cut down on the console traffic?
> >>
> > Nothing changes I still have endless repeats of
> >
> > parent transid verify failed on 1682586464256
On Sun, Jul 11, 2010 at 01:19:34AM -0700, Yee-Ting Li wrote:
> so after leaving the array for a while, with the disk churning away for a few
> days, it stopped. i copied some files off the disk (everything seems okay)
> and decided to unmount and run btrfsck again - this time i get a different
>
I have the same problem too, in general file deletion is very slow on
btrfs (at least for me).
On 11/7/2010 5:59 μμ, Lubos Kolouch wrote:
Hello,
during my testing of btrfs I found out,
that deletion of directory with many files (many millions) takes vry
long (it is running two weeks now a
Hello,
during my testing of btrfs I found out,
that deletion of directory with many files (many millions) takes vry
long (it is running two weeks now and did not finish).
But when instead of directory I create subvolume, it is deleted instantly.
Is it normal behaviour? (gentoo 2.6.34-r1, b
It's getting worse. The /home partition is now affected too. I get the Oops on
simple unmounting the fs. btrfsck gives me this output on this fs:
btrfsck /dev/mapper/sdb3
leaf 123780497408 items 49 free space 271 generation 62207 owner 2
fs uuid 7f013285-88d8-452f-a139-7d44bffd14b6
chunk uuid 36
I am trying to use EncFS in conjunction with btrfs and I ran into a
weird situation which I think is caused by statvfs being called on a
btrfs subvolume.
In particular, when I do something like the following:
statvfs("/mnt/btrfs-volume/some-subvolume")
then all mounted FUSE file-systems
so after leaving the array for a while, with the disk churning away for a few
days, it stopped. i copied some files off the disk (everything seems okay) and
decided to unmount and run btrfsck again - this time i get a different error:
$ sudo /usr/local/bin/btrfsck /dev/sdf
failed to read /dev/sr