This patch fixes the following problem:
- If we failed to deal with the delayed dir items, we should abort transaction,
just as its comment said. Fix it.
- If root reference or root back reference insertion failed, we should
abort transaction. Fix it.
- Do not restore the trans-rsv if we
The snapshot should be the image of the fs tree before it was created,
so the metadata of the snapshot should not exist in the its tree. But now, we
found the directory item and directory name index is in both the snapshot tree
and the fs tree. It introduces some problem and makes the users feel
This should obviously not be if (flag) but if (flag).
Signed-off-by: Stefan Behrens sbehr...@giantdisaster.de
---
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
---
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
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
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
alex.bolshoy.bt...@gmail.com wrote:
Alexander,
(pls let me know when this gets annoying:).
Parent:
/mnt/src/v2_snap0/
└── [
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
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,
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
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
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
abloc...@googlemail.com wrote:
I'm currently working on another solution for the initial problem. I
will create a for-alex branch for you to
On Thu, Jul 26, 2012 at 2:09 PM, Chris Mason chris.ma...@fusionio.com 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.
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_caches ;
13 matches
Mail list logo
