Original Message
Subject: Re: Should btrfs reuse the src_dev's dev UUID when doing dev
replacing?
From: Anand Jain
To: Qu Wenruo , linux-btrfs
Date: 2014年05月22日 11:09
Thanks Qu for bringing up this topic. We definitely need some focus
on the btrfs volume management re
Original Message
Subject: Re: Should btrfs reuse the src_dev's dev UUID when doing dev
replacing?
From: Anand Jain
To: Qu Wenruo , linux-btrfs
Date: 2014年05月22日 11:09
Thanks Qu for bringing up this topic. We definitely need some focus
on the btrfs volume management re
Man page for 'btrfs-balance' mentioned but does not explain
them, which make end users hard to use '-d', '-m' or '-s options.
This patch will use the explanations from
https://btrfs.wiki.kernel.org/index.php/Balance_Filters to enrich the
man page.
Signed-off-by: Qu Wenruo
---
Documentation/btr
man pages for btrfs-progs are compressed by gzip by default. In Makefile
the variable GZIP is use, this evaluates to 'gzip gzip' on my system.
>From man gzip:
> The environment variable GZIP can hold a set of default options for
> gzip. These options are interpreted first and can be overwritten by
Peter Chant posted on Mon, 02 Jun 2014 21:54:56 +0100 as excerpted:
>> What I /meant/ was "only defragging what you pointed the defrag at",
>> not the other snapshots of the same subvolume. "Mounted" shouldn't
>> have anything to do with it, except that I didn't consider the
>> possibility of hav
inline below.
On 30/05/2014 15:40, Anand Jain wrote:
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
On 06/03/2014 12:18 AM, David Sterba wrote:
On Thu, May 29, 2014 at 05:59:56PM +0800, Wang Shilong wrote:
The reason that we allow partial opening is that sometimes,
we may have some corrupted trees.(for example extent tree), for
fsck repair case, the broken tree may be rebuilt later.
So if use
when we replace the device its corresponding sysfs
entry has to be replaced as well
Signed-off-by: Anand Jain
---
v2: the function name change applied here
fs/btrfs/dev-replace.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/fs/btrfs/dev-replace.c b/fs/btrfs/dev-replace.c
index 9f22
we would need the device links to be created,
when device is added.
Signed-off-by: Anand Jain
---
v2: the function name change applied here
fs/btrfs/sysfs.c | 12 +---
fs/btrfs/sysfs.h | 2 ++
fs/btrfs/volumes.c | 5 +
3 files changed, 16 insertions(+), 3 deletions(-)
diff -
From: Anand Jain
Signed-off-by: Anand Jain
---
v2: this is a new patch in the patch-set sent before,
as per the review comments. Thanks David.
fs/btrfs/sysfs.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/btrfs/sysfs.c b/fs/btrfs/sysfs.c
index 522d023..41b0672
when we delete the device from the mounted btrfs,
we would need its corresponding sysfs enty to
be removed as well.
Signed-off-by: Anand Jain
---
v2: the function name change applied here
fs/btrfs/sysfs.c | 20
fs/btrfs/sysfs.h | 2 ++
fs/btrfs/volumes.c | 4
3
From: Anand Jain
As of now with out this patch the sysfs interface under dir
/sys/fs/btrfs//devices is just link to the block devs.
Moving forward we would need the above btrfs sysfs path to contain more
info about the btrfs devices. So this patch provides a framework for
the same.
And as of no
This patch set fixes the bugs which Jeff patch is fixing,
which is to update sysfs when device is added and removed.
Further, this patch set also address the following.
- Update sysfs path when device is replaced
- Update sysfs path when sprout is created
Also mainly this patch makes the code
Creating sprout will change the fsid of the mounted root.
do the same on the sysfs as well.
reproducer:
mount /dev/sdb /btrfs (seed disk)
btrfs dev add /dev/sdc /btrfs
mount -o rw,remount /btrfs
btrfs dev del /dev/sdb /btrfs
mount /dev/sdb /btrfs
Error:
kobject_add_internal failed for fe3504
On 06/03/2014 01:27 AM, David Sterba wrote:
On Thu, May 29, 2014 at 05:59:57PM +0800, Wang Shilong wrote:
If checksum root is corrupted, fsck will get segmentation. This
is because if we fail to load checksum root, root's node is NULL which
cause NULL pointer deferences later.
To fix this probl
On 02/06/2014 23:39, David Sterba wrote:
On Mon, Jun 02, 2014 at 04:22:20PM +0800, Anand Jain wrote:
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -2084,6 +2084,7 @@ int btrfs_init_new_device(struct btrfs_root *root, char
*device_path)
mutex_unlock(&root->fs_info->fs_devices->d
On Sat, May 31, 2014 at 6:48 PM, Philip Worrall
wrote:
> LZ4 is a lossless data compression algorithm that is focused on
> compression and decompression speed. LZ4 gives a slightly worse
> compression ratio compared with LZO (and much worse than Zlib)
> but compression speeds are *generally* simil
On 06/02/2014 12:55 PM, Arnd Bergmann wrote:
>>
>> The bit that is really going to hurt is every single ioctl that uses a
>> timespec.
>>
>> Honestly, though, I really don't understand the point with "struct
>> inode_time". It seems like the zeroeth-order thing is to change the
>> kernel internal
On Mon, 2 Jun 2014, Arnd Bergmann wrote:
> Ok. Sorry about missing linux-api, I confused it with linux-arch, which
> may not be as relevant here, except for the one question whether we
> actually want to have the new ABI on all 32-bit architectures or only
> as an opt-in for those that expect to s
On 06/01/2014 11:47 PM, Duncan wrote:
>>> Here's the deal. Due to scaling issues the original snapshot aware
>>> defrag code was recently disabled, so defrag now doesn't worry about
>>> snapshots, only defragging whatever is currently mounted. If you have
>>> a lot of fragmentation and are using
On Monday 02 June 2014 12:26:22 H. Peter Anvin wrote:
> On 06/02/2014 12:19 PM, Arnd Bergmann wrote:
> > On Monday 02 June 2014 13:52:19 Joseph S. Myers wrote:
> >> On Fri, 30 May 2014, Arnd Bergmann wrote:
> >>
> >>> a) is this the right approach in general? The previous discussion
> >>>pointe
Tl;dr tried nearly everything, couldn't get it to recover, gave up and
restored my old backup. I was running the newest Archlinux kernel
release.
.. Extracting data with Btrfs restore was quite useless, Btrfs find
root didn't list any object id's either, which I was unsure why. I
guess I was just
On 06/02/2014 12:19 PM, Arnd Bergmann wrote:
> On Monday 02 June 2014 13:52:19 Joseph S. Myers wrote:
>> On Fri, 30 May 2014, Arnd Bergmann wrote:
>>
>>> a) is this the right approach in general? The previous discussion
>>>pointed this way, but there may be other opinions.
>>
>> The syscall cha
On Monday 02 June 2014 13:52:19 Joseph S. Myers wrote:
> On Fri, 30 May 2014, Arnd Bergmann wrote:
>
> > a) is this the right approach in general? The previous discussion
> >pointed this way, but there may be other opinions.
>
> The syscall changes seem like the sort of thing I'd expect, alth
Hi.
Christian Kujau suggested in the wiki[] to post project ideas to the
list to give them some possible wider discussion.
So far I've had these ideas:
1) NFS 4 ACLs[1]
Not sure whether it has been proposed and/or rejected before),... but it
would be nice if it was a goal for btrfs to support NF
On Thu, May 29, 2014 at 08:52:04PM +0100, Mike Fleetwood wrote:
> On 29 May 2014 02:02, Qu Wenruo wrote:
> > The original print_dev_item() only prints device id,total bytes and
> > bytes used.
> > When it comes to debug things related to duplicated device id, dev uuid
> > is needed to distinguish
On Thu, May 29, 2014 at 05:59:57PM +0800, Wang Shilong wrote:
> If checksum root is corrupted, fsck will get segmentation. This
> is because if we fail to load checksum root, root's node is NULL which
> cause NULL pointer deferences later.
>
> To fix this problem, we just did something like extent
On Thu, May 29, 2014 at 05:59:56PM +0800, Wang Shilong wrote:
> The reason that we allow partial opening is that sometimes,
> we may have some corrupted trees.(for example extent tree), for
> fsck repair case, the broken tree may be rebuilt later.
>
> So if users only want to do check but not repa
On Thu, May 29, 2014 at 4:32 PM, Rasmus Eskola wrote:
> Hi,
>
> I'm trying to send an incremental backup of a btrfs subvolume to
> another host using the command:
>
> sudo btrfs send -v /home/backup/2014-05-29_02:26:38 | ssh "root@s"
> "btrfs receive -v /btrfs/backup_bulky/home"
>
> Eventually it
On Wed, May 28, 2014 at 07:20:38PM +0800, Wang Shilong wrote:
> --- a/cmds-check.c
> +++ b/cmds-check.c
> @@ -6810,8 +6810,7 @@ int cmd_check(int argc, char **argv)
> int option_index = 0;
> int init_csum_tree = 0;
> int qgroup_report = 0;
> - enum btrfs_open_ctree_flags ctree
On Mon, Jun 02, 2014 at 04:22:20PM +0800, Anand Jain wrote:
> >>--- a/fs/btrfs/volumes.c
> >>+++ b/fs/btrfs/volumes.c
> >>@@ -2084,6 +2084,7 @@ int btrfs_init_new_device(struct btrfs_root *root,
> >>char *device_path)
> >>mutex_unlock(&root->fs_info->fs_devices->device_list_mutex);
> >>
> >>
On Fri, 30 May 2014, Arnd Bergmann wrote:
> a) is this the right approach in general? The previous discussion
>pointed this way, but there may be other opinions.
The syscall changes seem like the sort of thing I'd expect, although
patches adding new syscalls or otherwise affecting the kernel
On 05/30/2014 06:00 PM, Martin wrote:
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 wh
On 06/01/2014 11:07 PM, Mitch Harder wrote:
On Sat, May 31, 2014 at 6:51 PM, Brendan Hide wrote:
On 2014/05/31 12:00 AM, Martin wrote:
OK... I'll jump in...
On 30/05/14 21:43, Josef Bacik wrote:
[snip]
Option 1: Only relink inodes that haven't changed since the snapshot was
taken.
Pros:
On 29/05/14 20:54, David Sterba wrote:
On Mon, May 26, 2014 at 05:30:26PM +0800, Anand Jain wrote:
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -2084,6 +2084,7 @@ int btrfs_init_new_device(struct btrfs_root *root, char
*device_path)
mutex_unlock(&root->fs_info->fs_devices->d
On 01. juni 2014 23:29, Marc MERLIN wrote:
On Wed, May 28, 2014 at 04:56:56PM +0200, Torbjørn wrote:
On 05/28/2014 03:41 PM, Chris Mason wrote:
On 05/28/2014 01:53 AM, Torbjørn wrote:
It's actually a raid10 array of 11 dm-crypt devices.
I'm able to read data from the array (accessing files),
36 matches
Mail list logo
