similar to: [PATCH] Canonicalise BTRFS: and Btrfs: to btrfs:

Hello, I want to throw this out here now that I''ve got most of the heavy lifting done for this code to make sure what I''m doing is ok for now. I''ve added an ORPHAN_DIR item key to have a hidden dir per root. Right now it just does it for whatever the default root is on mount, but I''m going to fix that to do the orphan dir check/creation on lookup of a

Hi there, Just gave 0.13 a spin against XFS (both with default mkfs options) on my SATA tower and was impressed by how much performance has improved since last time I played with it (v0.5)! It pretty much matched XFS for I/O performance and had much better file creation/deletion performance. http://www.csamuel.org/2008/03/23/btrfs-013-and-xfs-benchmarks cheers, Chris -- Chris Samuel :

Because orphan cleanup now happens well after the fs is all initialized and such, we can run into this problem where we find orphan entries that were just added to the fs, not ones that were added previously during a crash. This does not bode well for the system, and results in a couple of odd things happening, like truncate being run on non-regular files. In order to fix this we just check and

This patch was generated using the Coccinelle scripts and btrfs code in v2.6.36-9657-g7a3f8fe. Use ERR_CAST inlined function instead of ERR_PTR(PTR_ERR(...)) The semantic patch that makes this change is available in scripts/coccinelle/api/err_cast.cocci. More information about semantic patching is available at http://coccinelle.lip6.fr/ Signed-off-by: Chris Samuel

In fixing how we deal with bad inodes, we had a regression in the orphan cleanup code, since it expects to get a bad inode back. So fix it to deal with getting -ESTALE back by deleting the orphan item manually and moving on. Thanks, Reported-by: Simon Kirby <sim@hostway.ca> Signed-off-by: Josef Bacik <josef@redhat.com> --- fs/btrfs/inode.c | 36

Hi folks, For people who might be interested, here is how btrfs performs with two partitions on a single SSD drive in a RAID-1 mirror. This is on a Dell E4200 with Core 2 Duo U9300 (1.2GHz), 2GB RAM and a Samsung SSD (128GB Thin uSATA SSD). Version 1.03c ------Sequential Output------ --Sequential Input- --Random- -Per Chr- --Block-- -Rewrite- -Per Chr- --Block--

Hi Chris, et. al, I''ve recently come across cppcheck (static analyser for C code) and ran it on the current btrfs directory from Linus''s repo and it''s reported the following potential issues: linux-2.6$ cppcheck -q fs/btrfs/ [fs/btrfs/compression.c:343]: (error) Data is allocated but not initialized: cb [fs/btrfs/compression.c:583]: (error) Data is allocated but not

We do log replay in a single transaction, so it''s not good to do unbound operations during replaying log. This patch makes orphan inodes cleanup executed after replaying log. It also avoid doing other unbound operations such as truncating a file during replaying log. These unbound operations are postponed to the orphan inode cleanup stage. Signed-off-by: Yan Zheng

In support of the recently added capability to remount with lzo compression, provide a helper function to check the compression INCOMPAT flags when remounting with lzo compression, and set the flags if necessary. Also, implement the new helper function when defragmenting with explicit lzo compression and when setting the default subvolume. Signed-off-by: Mitch Harder

After running ceph on XFS for some time, I decided to try btrfs again. Performance with the current "for-linux-min" branch and big metadata is much better. The only problem (?) I''m still seeing is a warning that seems to occur from time to time: [87703.784552] ------------[ cut here ]------------ [87703.789759] WARNING: at fs/btrfs/inode.c:2103

The following case will make the incompat/compat flag of the super block be recovered. Task1 |Task2 flags = btrfs_super_incompat_flags(); | |flags = btrfs_super_incompat_flags(); flags |= new_flag1; | |flags |= new_flag2; btrfs_set_super_incompat_flags(flags); | |btrfs_set_super_incompat_flags(flags); the new_flag1 is recovered. In order to avoid this problem, we

Older kernels would generally be able to still mount the filesystem with the default subvolume set, but it would result in a different volume being mounted, which could be an even more unpleasant suprise for users. So if you set your default subvolume, you can''t go back to older kernels. Thanks, Signed-off-by: Josef Bacik <josef@redhat.com> --- fs/btrfs/ctree.h | 4 +++-

Andrew, can you please send this on to Linus and -stable ASAP? It's causing massive problems for our users. On Thu, Aug 12, 2010 at 04:50:59PM -0400, Jeff Moyer wrote: > Hi, > > commit c2c6ca4 (direct-io: do not merge logically non-contiguous > requests) introduced a bug whereby all O_DIRECT I/Os were submitted a > page at a time to the block layer. The problem is that the

Hello, My computer locked up and I had to press the reset button. Ever since then I can''t mount the btrfs filesystem, here''s the output: [ 37.645583] ------------[ cut here ]------------ [ 37.645598] WARNING: at fs/btrfs/free-space-cache.c:1887 btrfs_remove_free_space+0x329/0x350 [btrfs]() [ 37.645600] Modules linked in: btrfs zlib_deflate libcrc32c ext4 jbd2 mbcache crc16

tree: git://git.kernel.org/pub/scm/linux/kernel/git/josef/btrfs-next.git master head: 0cb8658e96f1ba2ff2d730224cb31e231edd318d commit: 7017ac470ed5b029bc683883714a7f4a4ed34c33 Btrfs: move some common code into a subfunction date: 2 days ago config: make ARCH=x86_64 allyesconfig All warnings: fs/btrfs/volumes.c: In function ''btrfs_rm_device'': fs/btrfs/volumes.c:1505:1:

This fixes up the progs to properly deal with skinny metadata. This adds the -x option to mkfs and btrfstune for enabling the skinny metadata option. This also makes changes to fsck so it can properly deal with the skinny metadata entries. Thanks, Signed-off-by: Josef Bacik <jbacik@fusionio.com> --- V2->V3: update the mkfs.btrfs man page with the new option This is based on

Hi, I`ve find about BtrFS just this week, so I`ve not tested it so far. I`ll do it as soon as I got a spare disk to experiment with. But, I`ve two questions regarding BtrFS. First, do you plan inclusion of BtrFS into mainline kernel and if so, when do you expect this to happen? Second, I would like to see some more benchmarks of BtrFS, so far you provided comparison to Ext3 and XFS, which is

Hello, I''m seeing a lot of warnings in dmesg with a BTRFS filesystem. I''m using the 3.1 kernel, I found a patch for these warnings ( http://marc.info/?l=linux-btrfs&m=131547325515336&w=2) <http://marc.info/?l=linux-btrfs&m=131547325515336&w=2>, but that patch has already been included in 3.1. Are there any other patches I can try? I''m using

Hello, This patch adds rollback support for the converter, the converter can roll back a conversion if the image file haven't been modified. In addition, I rearrange some codes in convert.c and add a few comments. Regards YZ --- diff -r 12138d4beeb0 convert.c --- a/convert.c Fri Jan 04 11:29:55 2008 -0500 +++ b/convert.c Mon Jan 07 23:35:25 2008 +0800 @@ -33,6 +33,7 @@ #include

Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c:584: warning: Function parameter or member 'init' not described in 'init_reserved' drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c:611: warning: expecting prototype for INIT_DONE(). Prototype was for init_done() instead [Snipped ~140 lines for brevity] Cc: Ben Skeggs <bskeggs at