Re: kernel BUG at fs/btrfs/inode.c:2299

[Maciej Marcin Piechotka <uzytkownik2@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1596 bytes --]

On Sat, 2011-09-17 at 20:30 +0200, Maciej Marcin Piechotka wrote:
> On Sat, 2011-09-17 at 20:25 +0200, Maciej Marcin Piechotka wrote:
> > 1. Once the blank screen happened ot 23:00 UTC instead of 03:00 UTC
> > 2. I tried to disable the caches
> > 3. I tried to rsync via ext3 + btrfs-convert. I noticed something - in
> > old fs the df looked like:
> > 
> > Data: total=30.01GB, used=28.42GB
> > System, DUP: total=8.00MB, used=4.00KB
> > System: total=4.00MB, used=0.00
> > Metadata, DUP: total=1.00GB, used=199.47MB
> > Metadata: total=8.00MB, used=0.00
> > 
> > on new one (with ext3 image):
> > Data: total=33.33GB, used=20.52GB
> > System: total=32.00MB, used=4.00KB
> > Metadata: total=16.64GB, used=11.36GB
> > 
> > and without:
> > Data: total=33.33GB, used=20.04GB
> > System: total=32.00MB, used=4.00KB
> > Metadata: total=16.64GB, used=10.88GB
> > 
> > Given that lzo compression was used about 4 GB data difference was
> > expected (difference depending on mount options on rsynbc). However:
> > 
> > 1. What is DUP?

Ok.After some digging I found out.

> > 2. Why metadata is so big on convertion from ext3 while data is small
> > (the sum is about right - 31GB vs 28.5GB)?
> > 

After rebalancing I got:

Data: total=32.00GB, used=30.83GB
System: total=32.00MB, used=12.00KB
Metadata: total=1.00GB, used=227.16MB  

> 
> That should be a) b)
> 
> 4. I think it triggered a bug with data loss - the new data was not
> written to disk despite being visible from userspace after mount during
> the same mount.
> 
> > Regards
> 
> 



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]