Thanks for the review David.
On 29/05/14 21:04, David Sterba wrote:
On Mon, May 26, 2014 at 05:30:23PM +0800, Anand Jain wrote:
--- a/fs/btrfs/sysfs.c
+++ b/fs/btrfs/sysfs.c
@@ -572,6 +572,26 @@ static void init_feature_attrs(void)
}
}
+int rm_device_membership(struct btrfs_fs_info
btrfs_punch_hole() will truncate unaligned pages or punch hole on a
already existed hole.
This will cause unneeded zero page or holes splitting the original huge
hole.
This patch will skip already existed holes before any page truncating or
hole punching.
Signed-off-by: Qu Wenruo
Hi Qu,
In line below...
On 16/04/14 17:02, Qu Wenruo wrote:
Btrfs will send uevent to udev inform the device change,
but ctime/mtime for the block device inode is not udpated, which cause
libblkid used by btrfs-progs unable to detect device change and use old
cache, causing 'btrfs dev
Original Message
Subject: Re: [PATCH RFC] btrfs: Add ctime/mtime update for btrfs device
add/remove.
From: Anand Jain anand.j...@oracle.com
To: Qu Wenruo quwen...@cn.fujitsu.com, linux-btrfs@vger.kernel.org
Date: 2014年05月30日 15:51
Hi Qu,
In line below...
On 16/04/14
Nack for this as of now. sorry. Qu finds, this doesn't fix.
my test case was dev delete and then ls -l dev by hand.
Qu's test case is same but a script. Looks like that time
gap is the key.
Looking more.
Thanks, Anand
On 30/05/14 15:50, Anand Jain wrote:
From: Anand Jain
On Fri, May 30, 2014 at 02:10:28PM +0800, Anand Jain wrote:
@@ -572,6 +572,26 @@ static void init_feature_attrs(void)
}
}
+int rm_device_membership(struct btrfs_fs_info *fs_info,
+ struct btrfs_device *one_device)
The name is too generic for a non-static function, so it
When cloning a range of a file, we were visiting all the extent items in
the btree that belong to our source inode. We don't need to visit those
extent items that don't overlap the range we are cloning, as doing so only
makes us waste time and do unnecessary btree navigations (btrfs_next_leaf)
for
In ioctl.c:lock_extent_range(), after locking our target range, the
ordered extent that btrfs_lookup_first_ordered_extent() returns us
may not overlap our target range at all. In this case we would just
unlock our target range, wait for any new ordered extents that overlap
the range to complete,
This is the most important patch ever. ;)
I found this to be less aesthetically pleasing than it was before:
[CC] btrfstune.o
Making all in Documentation
ASCIIDOC btrfs-convert.xml
[LD] btrfstune
XMLTO btrfs-convert.8
[CC] btrfs-show-super.o
GZIP
Hello,
Ok, I am turning to you guys as a last straw for help. Have been
running btrfs ontop of a LUKS encrypted device for some three months.
It's been working great up until last week, when I suddenly ended up
with an unmountable filesystem. This happened right after I woke up
the system from a
Le 05/21/14 19:20, Adam Buchbinder a écrit :
+ # 256MB is the smallest acceptable btrfs image.
+ dd if=/dev/zero of=$here/test.img bs=1024 count=$((256*1024)) \
+ convert-tests-results.txt 21 || _fail dd failed
What about using a sparse file to speed up the test and be
btrfs uses unsigned 64-bit seconds for inode timestamps, which will work
basically forever, but the VFS uses struct timespec for timestamps,
which is only good until 2038 on 32-bit CPUs.
This gets us one small step closer to lifting the VFS limit by using
struct inode_time in btrfs.
Hello,
TL;DR: I want to only do snapshot-aware defrag on inodes in snapshots
that haven't changed since the snapshot was taken. Yay or nay (with a
reason why for nay)
=== How snapshot aware defrag currently works ===
First the defrag stuff will go through and read in and mark dirty a big
If the NO_HOLES feature is enabled holes don't have file extent items in
the btree that represent them anymore. This made the clone operation
ignore the gaps that exist between consecutive file extent items and
therefore not create the holes at the destination.
A test case for xfstests follows.
When cloning a range of a file, we were visiting all the extent items in
the btree that belong to our source inode. We don't need to visit those
extent items that don't overlap the range we are cloning, as doing so only
makes us waste time and do unnecessary btree navigations (btrfs_next_leaf)
for
---
INSTALL |3 +++
1 file changed, 3 insertions(+)
diff --git a/INSTALL b/INSTALL
index 8ead607..2f15e5e 100644
--- a/INSTALL
+++ b/INSTALL
@@ -16,6 +16,9 @@ The Btrfs utility programs require libuuid to build. This
can be found
in the e2fsprogs sources, and is usually available as
16 matches
Mail list logo
