Re: [PATCH] Btrfs: make lzo the default compression scheme

On Fri, May 27, 2011 at 2:41 AM, Fajar A. Nugraha wrote: > On Fri, May 27, 2011 at 2:32 PM, Sander wrote: >> Li Zefan wrote (ao): >>> As the lzo compression feature has been established for quite >>> a while, we are now ready to replace zlib with lzo as the default >>> compression scheme. >> >> P

Re: [GIT PULL] Btrfs updates

One question. Will the autodefrag option be snapshot aware? Would enabling this option double the amount of used space if there is a snapshot present? On Fri, May 27, 2011 at 2:55 PM, Chris Mason wrote: > > Hi everyone, > > I always thought that I'd be retired and with my flying car at the > beac

Re: kernel BUG at fs/btrfs/inode.c:2271!

On 05/27/2011 03:23 PM, Marco Neubauer wrote: > > Am 25.05.2011 um 21:25 schrieb Josef Back: >> >> Hrm well that's doubly weird, the root should be right so it should be >> able to find the orphan item to delete it for the bad inode, and why the >> hell are we looping on that orphan item? Remove

[PATCH] Btrfs: fix the allocator loop logic

I was testing with empty_cluster = 0 to try and reproduce a problem and kept hitting early enospc panics. This was because our loop logic was a little confused. So this is what I did 1) Make the loop variable the ultimate decider on wether we should loop again isntead of checking to see if we ha

[GIT PULL] Btrfs updates

Hi everyone, I always thought that I'd be retired and with my flying car at the beach by the time 3.0 came out, but I've setup the for-linus branch of the btrfs-unstable tree for pulling: git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-unstable.git for-linus This pull request is probab

Re: kernel BUG at fs/btrfs/inode.c:2271!

Am 25.05.2011 um 21:25 schrieb Josef Back: > > Hrm well that's doubly weird, the root should be right so it should be > able to find the orphan item to delete it for the bad inode, and why the > hell are we looping on that orphan item? Remove the previous patch I > gave you and apply this one in

[PATCH] Btrfs: fix bitmap regression

In cleaning up the clustering code I accidently introduced a regression by adding bitmap entries to the cluster rb tree. The problem is if we've maxed out the number of bitmaps we can have for the block group we can only add free space to the bitmaps, but since the bitmap is on the cluster we can'

[PATCH] Btrfs: try to only do one btrfs_search_slot in do_setxattr

I've been watching how many btrfs_search_slot()'s we do and I noticed that when we create a file with selinux enabled we were doing 2 each time we initialize the security context. That's because we lookup the xattr first so we can delete it if we're setting a new value to an existing xattr. But i

Re: strange btrfs sub list output

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 27.05.2011 13:30, Stephane Chazelas wrote: > 2011-05-27 10:45:23 +0100, Hugo Mills: [...] >>> How could a "subvolume 285" become a "top level"? >> >>> How does one get a subvolume with a top-level other than "5"? >> >> This just means that subvolu

Re: strange btrfs sub list output

On Fri, May 27, 2011 at 12:30:10PM +0100, Stephane Chazelas wrote: > 2011-05-27 10:45:23 +0100, Hugo Mills: > [...] > > > How could a "subvolume 285" become a "top level"? > > > > > How does one get a subvolume with a top-level other than "5"? > > > >This just means that subvolume 287 was cre

Re: strange btrfs sub list output

2011-05-27 10:45:23 +0100, Hugo Mills: [...] > > How could a "subvolume 285" become a "top level"? > > > How does one get a subvolume with a top-level other than "5"? > >This just means that subvolume 287 was created (somewhere) inside > subvolume 285. > >Due to the way that the FS trees

Re: strange btrfs sub list output

On Fri, May 27, 2011 at 12:06:44PM +0200, Andreas Philipp wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 27.05.2011 11:45, Hugo Mills wrote: > > On Fri, May 27, 2011 at 10:30:29AM +0100, Stephane Chazelas wrote: > >> 2011-05-27 10:12:24 +0100, Hugo Mills: > >> [skipped useful

Re: strange btrfs sub list output

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 27.05.2011 11:45, Hugo Mills wrote: > On Fri, May 27, 2011 at 10:30:29AM +0100, Stephane Chazelas wrote: >> 2011-05-27 10:12:24 +0100, Hugo Mills: >> [skipped useful clarification] >>> >>> That's all rather dense, and probably too much information

Re: strange btrfs sub list output

On Fri, May 27, 2011 at 10:30:29AM +0100, Stephane Chazelas wrote: > 2011-05-27 10:12:24 +0100, Hugo Mills: > [skipped useful clarification] > > > >That's all rather dense, and probably too much information. Hope > > it's helpful, though. > [...] > > It is, thanks. > > How would one end up i

Re: strange btrfs sub list output

2011-05-27 10:12:24 +0100, Hugo Mills: [skipped useful clarification] > >That's all rather dense, and probably too much information. Hope > it's helpful, though. [...] It is, thanks. How would one end up in a situation where the output of "btrfs sub list ." has: ID 287 top level 285 path da

Re: strange btrfs sub list output

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 27.05.2011 11:12, Hugo Mills wrote: > On Fri, May 27, 2011 at 09:47:33AM +0100, Stephane Chazelas wrote: >> 2011-05-27 10:21:03 +0200, Andreas Philipp: >> [...] What do those top-level IDs mean by the way? >>> The top-level ID associated with

Re: strange btrfs sub list output

On Fri, May 27, 2011 at 09:47:33AM +0100, Stephane Chazelas wrote: > 2011-05-27 10:21:03 +0200, Andreas Philipp: > [...] > > > What do those top-level IDs mean by the way? > > The top-level ID associated with a subvolume is NOT the ID of this > > particular subvolume but of the subvolume containing

Re: strange btrfs sub list output

Is there a way to derive the subvolume ID from the stat(2) st_dev, by the way. # btrfs sub list . ID 256 top level 5 path a ID 257 top level 5 path b # zstat +dev . a b . 27 a 28 b 29 Are the dev numbers allocated in the same order as the subvolids? Would there be any /sys, /proc, ioctl interface

Re: strange btrfs sub list output

2011-05-27 10:21:03 +0200, Andreas Philipp: [...] > > What do those top-level IDs mean by the way? > The top-level ID associated with a subvolume is NOT the ID of this > particular subvolume but of the subvolume containing it. Since the > "root/initial" (sub-)volume has always ID 0, the subvolumes

Re: strange btrfs sub list output

On 27.05.2011 10:01, Stephane Chazelas wrote: > 2011-05-26 22:22:03 +0100, Stephane Chazelas: [...] >> I get a btrfs sub list output that I don't understand: >> >> # btrfs sub list /backup/ ID 257 top level 5 path >> u1/linux/lvm+btrfs/storage/data/data ID 260 top level 5 path >> u2/linux/lvm/linux

Re: strange btrfs sub list output

2011-05-26 22:22:03 +0100, Stephane Chazelas: [...] > I get a btrfs sub list output that I don't understand: > > # btrfs sub list /backup/ > ID 257 top level 5 path u1/linux/lvm+btrfs/storage/data/data > ID 260 top level 5 path u2/linux/lvm/linux/var/data > ID 262 top level 5 path u1/linux/lvm+btr

Re: [PATCH] Btrfs: make lzo the default compression scheme

On Fri, May 27, 2011 at 2:32 PM, Sander wrote: > Li Zefan wrote (ao): >> As the lzo compression feature has been established for quite >> a while, we are now ready to replace zlib with lzo as the default >> compression scheme. > > Please be aware that grub2 currently can't load files from a btrfs

Re: [PATCH] Btrfs: make lzo the default compression scheme

Li Zefan wrote (ao): > As the lzo compression feature has been established for quite > a while, we are now ready to replace zlib with lzo as the default > compression scheme. Please be aware that grub2 currently can't load files from a btrfs with lzo compression (on debian sid/experimental at leas