Tests file clone functionality of btrfs (reflinks):
- Reflink a file
- Reflink the reflinked file
- Modify the original file
- Modify the reflinked file
[sandeen: add helpers, make several mostly-cosmetic
changes to the original testcase]
Signed-off-by: Koen De Wit
Tests file clone functionality of btrfs (reflinks) on directory trees.
- Create directory and subdirectory, each having one file
- Create 2 recursive reflinked copies of the tree
- Modify the original files
- Modify one of the copies
[sandeen: mostly cosmetic changes]
Signed-off-by:
Moving and deleting cloned (reflinked) files on btrfs:
- Create a file and a reflink
- Move both to a directory
- Delete the original (moved) file, check that the copy still exists.
[sandeen: mostly cosmetic changes]
Signed-off-by: Koen De Wit koen.de@oracle.com
Signed-off-by: Eric
Check if creating a sparse copy (reflink) of a file on btrfs
expectedly fails when it's done between different filesystems or
different mount points of the same filesystem.
For both situations, these actions are executed:
- Copy a file with the reflink=auto option.
A normal copy should be
On Thu, Jan 16, 2014 at 09:22:57PM -0500, Ivan Jager wrote:
After patching this I realized Liu Bo had already written a similar
patch, but I think mine is cleaner, so I'm sending it anyway.
Thanks for taking the time, I like your version better and will replace
Liu Bo's patch in integration
On Thu, Jan 16, 2014 at 08:02:58PM -0800, ivo welch wrote:
FAQ:
[1] where should I send FAQ questions or suggestions?
Good question, we need some place for that. Do you think that a section
on the FAQ page would be good enough? I'm not the right person to judge
that, my POV is different.
On Thu, Jan 16, 2014 at 01:38:10PM +0800, Wang Shilong wrote:
This problem should be fixed by Filipe, and pused into josef's btrfs-next:-)
patch url is:
https://git.kernel.org/cgit/linux/kernel/git/josef/btrfs-next.git/commit/?id=5d157162be99f950a0b64b526c04dff03f8c4eeb
For the recrod, the
Our problem is a zfs with 20,000 quota-enabled homedirectories and 100
snapshots.
We would really like to do the same with btrfs, but we don't know how to
replace the
zfs quotas with btrfs subvolume quotas. It seems unfeasible to handle 2,000,000
subvolumes.
e.g. we would have to create every
On Thu, Jan 16, 2014 at 07:23:18PM +, Toggenburger Lukas wrote:
Hi all
I'm a student of ICT currently doing my master's degree besides working as
a research assistant. Currently I'm looking for topics for my master thesis.
One of my ideas was to work on Btrfs. I studied the list of project
On Wed, Jan 15, 2014 at 09:35:17AM +0800, Liu Bo wrote:
@@ -430,6 +430,15 @@ struct btrfs_ioctl_get_dev_stats {
__u64 unused[128 - 2 - BTRFS_DEV_STAT_VALUES_MAX]; /* pad to 1k */
};
+/* deduplication control ioctl modes */
+#define BTRFS_DEDUP_CTL_ENABLE 1
+#define
On Fri, Jan 17, 2014 at 8:58 AM, David Sterba dste...@suse.cz wrote:
I'll put your analysis as a changelog and the missing Signed-off-by
line from your name + email.
It's the Developer's Certificate of Origin 1.1, see
http://lxr.free-electrons.com/source/Documentation/SubmittingPatches#L307
On Thu, Jan 16, 2014 at 07:23:18PM +, Toggenburger Lukas wrote:
Hi all
I'm a student of ICT currently doing my master's degree besides
working as a research assistant. Currently I'm looking for topics for
my master thesis. One of my ideas was to work on Btrfs. I studied the
list of
Hi,
Not sure if my previous email was received as I sent it from my phone. I
had to dd the disk off and then losetup mount the image. What do you
mean by erase the data on loop7? I have tried to mount separately without
success.
On Friday, 17.01.14 at 10:27, Miao Xie wrote:
On Thu, 16 Jan 2014
Martin Walter posted on Fri, 17 Jan 2014 15:18:41 +0100 as excerpted:
Our problem is a zfs with 20,000 quota-enabled homedirectories and 100
snapshots.
We would really like to do the same with btrfs, but we don't know how to
replace the zfs quotas with btrfs subvolume quotas. It seems
I'd like to know if there are drawbacks in using btrfs with non-ECC RAM instead
of using ext4 with non-ECC RAM. I know that some features of btrfs may rely on
ECC RAM but is the chance of data corruption or even a damaged filesystem
higher than when i use ext4 instead of btrfs?
I want to know
On 01/17/2014 01:33 PM, valleysmail-l...@yahoo.de wrote:
I'd like to know if there are drawbacks in using btrfs with non-ECC
RAM instead of using ext4 with non-ECC RAM. I know that some
features of btrfs may rely on ECC RAM but is the chance of data
corruption or even a damaged filesystem
Looking into some performance related issues with large amounts of metadata
revealed that we can have some pretty huge swings in fsync() performance. If we
have a lot of delayed refs backed up (as you will tend to do with lots of
metadata) fsync() will wander off and try to run some of those
valleysmail-l...@yahoo.de posted on Fri, 17 Jan 2014 18:33:35 + as
excerpted:
I'd like to know if there are drawbacks in using btrfs with non-ECC RAM
instead of using ext4 with non-ECC RAM. I know that some features of
btrfs may rely on ECC RAM
Crossed signals somewhere, as that's
This patch series adds a new ioctl TREE_SEARCH_V2 with which we could store the
results in a varying buffer. Now even items larger than 3992 bytes or a large
amount of items can be returned.
I have a few questions:
Which value should I assign to TREE_SEARCH_V2?
Should we limit the buffer
On Wed, 15 Jan 2014 21:22:08 +0100
Tomasz Chmielewski man...@wpkg.org wrote:
What kernel version? Can you:
umount
dmesg -n7
mount
And then try to reproduce the behavior and note any kernel messages
in dmesg?
Turns out it's reproducible, with 3.13-rc8.
After reboot, I've
rewrite search_ioctl to accept a buffer with varying size
Signed-off-by: Gerhard Heift gerh...@heift.name
---
fs/btrfs/ioctl.c | 19 ---
1 file changed, 12 insertions(+), 7 deletions(-)
diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
index 3970f32..be4c780 100644
---
By copying each found item seperatly to userspace, we only need a small amount
of memory in the kernel. This allows to run a large search inside of a single
call.
Signed-off-by: Gerhard Heift gerh...@heift.name
---
fs/btrfs/ioctl.c | 105 +--
1
To prevent unexpectet values in the unused fields of the search key fail early.
Otherwise future extensions would break the behavior of the search if current
implementations in userspace set them to values other than zero.
Signed-off-by: Gerhard Heift gerh...@heift.name
---
fs/btrfs/ioctl.c | 3
This new ioctl call allows the user to supply a buffer of varying size in which
a tree search can store its results. This is much more flexible if you want to
receive items which are larger than the current fixed buffer of 3992 bytes or
if you want to fetch mor item at once.
Currently the buffer
In copy_to_sk, if an item is too large for the given buffer, it now returns
-EOVERFLOW instead of copying a search_header with len = 0. For backward
compatibility for the first item it still copies such a header to the buffer,
but not any other following items, which could have fitted.
Hi,
I have been reading a lot of articles online about the dangers of using ZFS
with non-ECC RAM. Specifically, the fact that when good data is read from disk
and compared with its checksum, a RAM error can cause the read data to be
incorrect, causing a checksum failure, and the bad data
On Fri, Jan 17, 2014 at 6:23 PM, Ian Hinder ian.hin...@aei.mpg.de wrote:
Hi,
I have been reading a lot of articles online about the dangers of using ZFS
with non-ECC RAM. Specifically, the fact that when good data is read from
disk and compared with its checksum, a RAM error can cause the
On 18.01.2014 00:18, Duncan wrote:
valleysmail-l...@yahoo.de posted on Fri, 17 Jan 2014 18:33:35 + as
excerpted:
I'd like to know if there are drawbacks in using btrfs with non-ECC RAM
instead of using ext4 with non-ECC RAM. I know that some features of
btrfs may rely on ECC RAM
On 01/17/2014 04:23 PM, Ian Hinder wrote:
Hi,
I have been reading a lot of articles online about the dangers of using ZFS with non-ECC
RAM. Specifically, the fact that when good data is read from disk and compared with its
checksum, a RAM error can cause the read data to be incorrect,
On Sat, Jan 18, 2014 at 1:33 AM, valleysmail-l...@yahoo.de
valleysmail-l...@yahoo.de wrote:
I'd like to know if there are drawbacks in using btrfs with non-ECC RAM
instead of using ext4 with non-ECC RAM.
Non-ECC RAM can cause problems no matter what fs you use.
I know that some features
To start off, I have an encrypted LVM setup with a root logical volume and a
home
logical volume. Today decided to upgrade my home LV to btrfs for
compression. I installed btrfs-progs, unmounted /home, and ran
btrfs-convert /dev/MyVolumeGroup/home
and it completed with no errors reported. I
Steps to reproduce:
# mkfs.btrfs -f /dev/sda8
# mount /dev/sda8 /mnt
# btrfs sub snapshot -r /mnt /mnt/snap1
# btrfs sub snapshot -r /mnt /mnt/snap2
# btrfs send /mnt/snap1 -p /mnt/snap2 -f /mnt/1
# dmesg
The problem is that we will sort clone roots(include @send_root), it
might push
Hi Dave,
On 01/14/2014 11:27 PM, David Sterba wrote:
On Thu, Jan 09, 2014 at 02:52:27PM +, Chris Mason wrote:
You may need to upgrade the kernel to get new features offered by a
new userspace, but I think we should absolutely not be changing
userspace in a way that makes it
Ian Hinder posted on Sat, 18 Jan 2014 01:23:41 +0100 as excerpted:
I have been reading a lot of articles online about the dangers of using
ZFS with non-ECC RAM. Specifically, the fact that when good data is
read from disk and compared with its checksum, a RAM error can cause the
read data to
On Tue, 14 Jan 2014 10:17:19 AM Chris Murphy wrote:
-c 9 is max compression although I don't know what algorithm btrfs-image
uses off hand. If I use xz on it, 193MB becomes 192MB.
Be interesting to generate the same image without compression in btrfs-image
and then xz it, in case it can do
i did a `btrfs file convert -dconvert=raid10,soft /data`, which converted the
whole filesystem back to raid10, it completed without errors.
then i did a `btrfs convert -dconvert=raid1 /data`, which completed with 184
ENOSPC errors, exactly the same amount as before the covert back to raid10
36 matches
Mail list logo
