[PATCH] Btrfs: fix a misplaced address operator in a condition

2012-07-26 Thread Stefan Behrens
This should obviously not be "if (&flag)" but "if (flag)". Signed-off-by: Stefan Behrens --- fs/btrfs/locking.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/btrfs/locking.c b/fs/btrfs/locking.c index a44eff074..2a1762c 100644 --- a/fs/btrfs/locking.c +++ b/fs/btrfs/lock

Re: btrfs send/receive: if new inode ino is less than its new directory ino, incorrect path is sent

2012-07-26 Thread Alex Lyakas
Hi Alexander, I did some very initial testing, and there is still an issue. The logic of finish_outoforder_dir works as expected. But then problem is that later, when we process xattr/extents or finish the inode, the code still uses get_cur_path(), which brings an incorrect name. Consider the foll

Re: btrfs send/receive: if new inode ino is less than its new directory ino, incorrect path is sent

2012-07-26 Thread Alex Lyakas
Alexander, (pls let me know when this gets annoying:). Parent: /mnt/src/v2_snap0/ └── [257] file1 Send: /mnt/src/v2_snap1 └── [259] dir1 └── [258] dir2 └── [257] file1 I encountered two problems: 1) process_recorded_refs_if_needed() if needed does not call process

Re: btrfs send/receive: if new inode ino is less than its new directory ino, incorrect path is sent

2012-07-26 Thread Alexander Block
I'm currently working on another solution for the initial problem. I will create a for-alex branch for you to test later. On Thu, Jul 26, 2012 at 4:04 PM, Alex Lyakas wrote: > Alexander, > (pls let me know when this gets annoying:). > > Parent: > /mnt/src/v2_snap0/ > └── [257] file1 > > Send

Re: No/bad auto-detection of fs type for small volumes (related to mixed metadata/data?)

2012-07-26 Thread David Sterba
On Tue, Jul 24, 2012 at 08:39:36PM -0400, Marios Titas wrote: > When I create a btrfs volume of size strictly less than 256 MiB then if I do > mount /dev/sdb1 /mnt/test > the kernel tries unsuccessfully to do the mount with many other file systems > before successfully trying with btrfs. For vo

[next] kernel BUG at fs/btrfs/relocation.c:2331!

2012-07-26 Thread David Sterba
Hi, while testing a branch that'll become the next pull or so, I've hit $subj crash. (top commit: Chris Mason [cmason/next] Btrfs: uninit variable fixes in send/receive) # btrfs fi df /mnt/sdc Data: total=34.01GB, used=26.53GB System, DUP: total=8.00MB, used=12.00KB System: total=4.00MB, used=0.

[GIT PULL] a large btrfs update

2012-07-26 Thread Chris Mason
Hi Linus, Since this has a conflict, I've split it into two branches. # against 3.5, my diffstat is based on this branch git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git for-linus # against your git as of today git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.gi

Re: mkfs devices ordering relevant with devices of different sizes?

2012-07-26 Thread David Sterba
On Wed, Jul 25, 2012 at 03:26:20PM +0200, Cyril B. wrote: > When creating a filesystem with devices of different sizes, the resulting > filesystem total size depends on the device order specified to mkfs. When > the smaller device is specified first, the second (larger) device is seen as > the

Re: btrfs send/receive: if new inode ino is less than its new directory ino, incorrect path is sent

2012-07-26 Thread Alexander Block
I have pushed a for-alex branch to github with a new approach for the whole problem. Can you test this? On Thu, Jul 26, 2012 at 4:07 PM, Alexander Block wrote: > I'm currently working on another solution for the initial problem. I > will create a for-alex branch for you to test later. > > On Thu,

Re: [GIT PULL] a large btrfs update

2012-07-26 Thread Linus Torvalds
On Thu, Jul 26, 2012 at 2:09 PM, Chris Mason wrote: > > for-linus-merged has an extra commit on top as well that changes the > btrfs send/receive code to Al's new dentry_open. It's a small commit, > and my guess is that you'll cherry pick it and do your own merge. Indeed. And I dd the semantic m

Re: How can btrfs take 23sec to stat 23K files from an SSD?

2012-07-26 Thread Marc MERLIN
On Tue, Jul 24, 2012 at 09:56:26AM +0200, Martin Steigerwald wrote: > find is fast, du is much slower: > > merkaba:~> echo 3 > /proc/sys/vm/drop_caches ; time ( find /usr | wc -l ) > 404166 > ( find /usr | wc -l; ) 0,03s user 0,07s system 1% cpu 9,212 total > merkaba:~> echo 3 > /proc/sys/vm/drop