Signed-off-by: Augusto Mecking Caringi
---
INSTALL | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/INSTALL b/INSTALL
index 8ead607..9a4ab64 100644
--- a/INSTALL
+++ b/INSTALL
@@ -12,9 +12,16 @@ complete:
modprobe libcrc32c
insmod btrfs.ko
-The Btrfs utilit
Is there anything else I can do? I still have the file and should be
able to provide more data if needed.
2014-05-11 8:12 GMT+02:00 Ronald :
> Forgot to mention that these btrfs partitions reside on an LVM.
>
> 2014-05-11 7:56 GMT+02:00 Ronald :
>> Dear btrfs developers,
>>
>> Since v3.14, it has
---
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 libuui
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
Regression test for the btrfs ioctl clone operation when the source range
contains hole(s) and the FS has the NO_HOLES feature enabled (file holes
don't need file extent items in the btree to represent them).
This issue is fixed by the following linux kernel btrfs patch:
Btrfs: fix clone to d
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.
S
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
OK... I'll jump in...
On 30/05/14 21:43, Josef Bacik wrote:
> 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)
[...]
>
> === Summary and what I need ===
>
> Option 1:
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
a
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.
Signed-off-by
Based on the recent discussion about 64-bit time_t for new
architectures, and for solving the year 2038 problem in general,
I decided to try out what it would take to solve part of the
kernel side of things.
This is a proof-of-concept work to get us to the point where
two system calls (utimes and
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 2>&1 || _fail "dd failed"
What about using a sparse file to speed up the test an
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 h
When I made all the btrfs-foo.c targets generic, I somehow
managed to break the libs definition for btrfs-fragments by
dropping the "s" off the end.
Fix that, although apparently nobody is building this tool. :)
Signed-off-by: Eric Sandeen
---
As an aside, since it's not built by default, it s
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 btrfs-
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, lo
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
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-sta
Am I correct in believing that BTRFS has no support for locating metadata near
the data it refers to? The way it allocates 256M chunks for metadata and 1G
chunks for data seems to work against the possibility of locating metadata
near the data it refers to.
If this is correct then would it be
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
reprodu
Regression test for resizing 'thread_pool' when remount the fs.
Signed-off-by: Xing Gu
---
tests/btrfs/055 | 55 +
tests/btrfs/055.out | 1 +
tests/btrfs/group | 1 +
3 files changed, 57 insertions(+)
create mode 100755 tests/btrfs/055
Original Message
Subject: Re: [PATCH RFC] btrfs: Add ctime/mtime update for btrfs device
add/remove.
From: Anand Jain
To: Qu Wenruo , linux-btrfs@vger.kernel.org
Date: 2014年05月30日 15:51
Hi Qu,
In line below...
On 16/04/14 17:02, Qu Wenruo wrote:
Btrfs will send ueven
I have sent this
[PATCH] btrfs: kobject_uevent should use bd_part instead of bd_disk
which should fix. Could you try and update.
Thanks, Anand
On 30/05/14 15:51, Anand Jain wrote:
Hi Qu,
In line below...
On 16/04/14 17:02, Qu Wenruo wrote:
Btrfs will send uevent to udev inform the d
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 scan
From: Anand Jain
reproducer 1:
mkfs.btrfs -L test /dev/sdg1
mount LABEL=test /btrfs
btrfs dev add /dev/sdg2 /btrfs
btrfs dev del /dev/sdg1 /btrfs
umount /btrfs
mount LABEL=test /btrfs
mount: special device LABEL-test1 does not exist
It does not reproduce this problem when whole disk is
On 29/05/14 21:29, David Sterba wrote:
On Mon, May 26, 2014 at 05:30:25PM +0800, Anand Jain wrote:
when we replace the device its corresponding sysfs
entry has to be replaced as well
Signed-off-by: Anand Jain
---
fs/btrfs/dev-replace.c |5 +
1 files changed, 5 insertions(+), 0 de
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
---
fs/btrfs/f
27 matches
Mail list logo