similar to: Sorry for redundant mail sending to the list

I made an attempt to partly decrease fragment by using a preallocated area of multiple size of a std blocksize for a tree block when it is COWed. The basic idea is that if any a tree block need to be created, we offer, say, 2 or 4 multiples of a std blocksize for it, then use the first block in the continuous blocks. When this block need a cow in the future, a new free block in these continuous

Hello, The question below is based on https://lists.ubuntu.com/archives/xubuntu-users/2012- August/004509.html Thanks in advance for any help with the following question, including pointing me to some other info resource if needed. I have a user with an Xubuntu 12.04.1 laptop, 32-bit. He needs to use a USB hard disk drive which has 2 partitions: the 1st partition is NTFS and the 2nd

Hello there, I just ran the sourceforge tool cppcheck over the source code of the new Linux kernel 2.6.32.4 It said 1. [./btrfs/free-space-cache.c:600]: (style) Redundant condition. It is safe to deallocate a NULL pointer The source code is                 if (info->bitmap)                         kfree(info->bitmap); I agree with cppcheck. Suggest delete the if test. 2.

This fixes bugzilla 57491. If we take a snapshot of a fs with a unlink ongoing and then try to send that root we will run into problems. When comparing with a parent root we will search the parents and the send roots commit_root, which if we''ve just created the snapshot will include the file that needs to be evicted by the orphan cleanup. So when we find a changed extent we will try

Hi there, i''m trying to send/receive a snapshot of my home dir for some time now, but in the end it always fails because the maximum number of open fd''s is exceeded. Kern log says: "6,7226,15012711248,-;VFS: file-max limit 799969 reached" My setup is as follows: Kernel: 3.9-rc5 btrfs-progs: compiled from git commit: commit

A user reported a bug where we do sizeof(*ptr * count) instead of sizeof(*ptr) * count. Fix this. Reported-by: David Binderman <dcb314@hotmail.com> Signed-off-by: Josef Bacik <jbacik@fusionio.com> --- fs/btrfs/send.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/btrfs/send.c b/fs/btrfs/send.c index ff40f1c..7c8964b 100644 --- a/fs/btrfs/send.c +++

I'm experimenting with btrfs-send. Previously (2014-09-26), I did my first btrfs-send on a subvol, and that worked fine. Today, I tried to send a new snapshot. Unfortunately, I realized part way through that I forgot to specify the parent to only send a delta, and killed the send with ^C. On the destination, I'm left with: ~$ sudo btrfs subvol list /var/media/backups/venus/home/ ID 2820

btrfs_commit_transaction will free our trans, but because we pass trans to shrink_delalloc we could possibly have a use after free situation. So instead if we commit the transaction, set trans to null and set committed to true so we don''t keep trying to commit a transaction. This fixes a panic I could reproduce at will. Thanks, Signed-off-by: Josef Bacik <josef@redhat.com> ---

I believe what I am going to write is a bug report. When I finaly did # btrfs send -v /mnt/adama-docs/backups/20130101-192722 | btrfs receive /mnt/tmp/backups to migrate btrfs from one partition layout to another. After a while system keeps saying that "Too many open files in system" and denies access to almost every command line tool. When I had access to iostat I confirmed the

Hi. In btrfs, fdatasync and fsync are identical. I think fdatasync should skip committing transaction when inode->i_state is set just I_DIRTY_SYNC and this indicates only atime or/and mtime updates. Following patch improves fdatasync throughput. #sysbench --num-threads=16 --max-requests=10000 --test=fileio --file-block-size=4K --file-total-size=16G --file-test-mode=rndwr

This check for a user transaction is a bogus: fsync() with an open user transaction is verboten. If the caller is the same process who started a user transaction, and this is a different file, we will deadlock. If it''s the same file, this check means we won''t deadlock, but the transaction will be prematurely closed out. Any user transaction ioctl users should be careful to

Hi everyone, I was trying the new send/receive feature today but can''t make it work. These are the commands I was using: btrfs subvol snap -r /mnt/data1/@downloads/ /mnt/data1/snapshots/testsnap btrfs send /mnt/data1/snapshots/testsnap | btrfs receive /mnt/data1/snapshots/testreceive/ This command never finishes. A ''ls /mnt/data1/snapshots/testreceive/ '' never

HI all, >----Messaggio originale---- >Da: chris.mason@fusionio.com >Data: 20/06/2012 1.49 >A: "H. Peter Anvin"<hpa@zytor.com> >Cc: "linux-btrfs@vger.kernel.org"<linux-btrfs@vger.kernel.org> >Ogg: Re: Subvolumes and /proc/self/mountinfo > >> b. Are there better ways (walking the tree using BTRFS_IOC_TREE_SEARCH?) >> to accomplish

Hi Thomas, >----Messaggio originale---- >Da: thomas@kupper.org >Data: 22/01/2010 10.48 >A: "Leszek Ciesielski"<skolima@gmail.com> >Cc: "linux-btrfs"<linux-btrfs@vger.kernel.org> >Ogg: Re: mount command not honoring rootflags passed > > >On 22 Jan 2010, at 10:40, Leszek Ciesielski wrote: > >> On Fri, Jan 22, 2010 at 10:30 AM,

Hello, We''re a team of 4 final year computer science students and are working on generating a diff between file system snapshots using the send receive code. The output of our utility looks like this- (I''ve tested it on a small subvol with minimal changes just to give an idea) root@nafisa-M-6319:/mnt/btrfs# btrfs sub diff -p /mnt/btrfs/snap1 /mnt/btrfs/snap2

In clear_extent_bit, it is enough that next node is adjacent in tree level. Signed-off-by: Liu Bo <liubo2009@cn.fujitsu.com> --- fs/btrfs/extent_io.c | 3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c index fcf77e1..e941cc4 100644 --- a/fs/btrfs/extent_io.c +++ b/fs/btrfs/extent_io.c @@ -577,8 +577,7 @@ hit_next: if

Hello insiders is there low level support to change inode ctimes somehow? (on ext[234] it can be done using debugfs) It would be nice to make received snapshots as similar as possible to their send source. (I am not talking about uuids and such, just ls -lc output) creative ideas are welcome, Karl -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body

I''m not sure how the numbering is supposed to work now that we''ve split everything out so I''m just going with the next number in the directory. This is a regression test for btrfs send, we had a problem where we''d try to send a file that had been deleted in the source snapshot. This is just to make sure we don''t have the same problem in the future.

We discussed using the top bits of the chunk type field field to store a number of redundant disks -- so instead of RAID5, RAID6, etc., we end up with a single ''RAID56'' flag, and the amount of redundancy is stored elsewhere. This attempts it, but I hate it and don''t really want to do it. The type field is designed as a bitmask, and _used_ as a bitmask in a number of

Hey guys, I was trying to build the btrfs modules from btrfs- unstable.git/master against the Ubuntu Karmic 2.6.31 kernel, and get some failures in ref-cache.c: /home/jdong/code/kernel/btrfs-0.17/ref-cache.h:62: error: dereferencing pointer to incomplete type /home/jdong/code/kernel/btrfs-0.17/ref-cache.c: In function ‘btrfs_remove_leaf_refs’: