On Sun, 4 Aug 2013 03:37:22 PM Bart Noordervliet wrote:
> a sufficiently up-to-date kernel and btrfs tool will provide the
> 'btrfs device stats' command, which should give you the info you want.
This is what it looks like:
chris@quad:~/Downloads/Linux/FileSystems/BtrFS/btrfs-progs$ sudo ./btrfs
btrfs fi show
Label: none uuid: e7aae9f0-1aa8-41f5-8fb6-d4d8f80cdb2c
Total devices 1 FS bytes used 28.00KiB
devid2 size 2.00GiB used 0.00 path /dev/sdc <-- WRONG
devid1 size 2.00GiB used 20.00MiB path /dev/sdb
Ok, now it's findable. Isn't that exactly ho
On Fri, Aug 09, 2013 at 06:16:30PM -0500, Eric Sandeen wrote:
> Ok, fair enough - so preferred is
>
> function(some args . . ,
> . . . more args . . .,
> . . . last args)
Yeah something like that, bonus points if variable type and name
On 8/9/13 5:48 PM, David Sterba wrote:
> On Fri, Aug 09, 2013 at 03:20:47PM -0500, Eric Sandeen wrote:
>> Mark many functions as static, and remove any resulting dead code.
>
> Thanks.
>
>> -struct btrfs_root *link_subvol(struct btrfs_root *root, const char *base,
>> - u
On Fri, Aug 09, 2013 at 03:20:47PM -0500, Eric Sandeen wrote:
> Mark many functions as static, and remove any resulting dead code.
Thanks.
> -struct btrfs_root *link_subvol(struct btrfs_root *root, const char *base,
> -u64 root_objectid)
> +static struct btrfs_root *
>
Josef Bacik schrieb:
>> So I guess the reason that ZFS does well with that workload is that
>> ZFS is using smaller blocks, maybe just 512B ?
>
> Yeah I'm not sure what ZFS does, but if you are writing over a block and
> the size/offset isn't aligned then you'd see similar issues with ZFS since
On Fri, Aug 09, 2013 at 01:37:14PM -0700, Zach Brown wrote:
> Device removal currently causes bdev removal to try to double free a bh
> in the bdev:
>
> [ 55.714833] WARNING: at fs/buffer.c:1160 __brelse+0x36/0x40()
> [ 55.714833] VFS: brelse: Trying to free free buffer
>
> Commit 7e3d9ebb1 a
On 7/25/13 12:29 PM, Anand Jain wrote:
> There is a very less chance that all the copies of SB
> on the disk is zeroed unintentionally. unless device
> is removed, so this fix will ensure all copies on the
> disk is zeroed when the disk is intentionally removed.
>
> reproducer:
> -
Commit 1104a8855 added an error branch that forgot to release the super
bh. I found this while looking for an unrelated double brelse.
Signed-off-by: Zach Brown
---
fs/btrfs/disk-io.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c
index 254cdc8..ca1e
Device removal currently causes bdev removal to try to double free a bh
in the bdev:
[ 55.714833] WARNING: at fs/buffer.c:1160 __brelse+0x36/0x40()
[ 55.714833] VFS: brelse: Trying to free free buffer
Commit 7e3d9ebb1 added a double release of the bh for a device being
removed when all the su
Mark many functions as static, and remove any resulting dead code.
Signed-off-by: Eric Sandeen
---
V2: Keep the "special" subvol_uuid_search_add()-which-only-frees-pointers
because I'm picking my battles :)
btrfs-convert.c |8
btrfs-find-root.c |2 +-
btrfs-list.c
Quoting Sage Weil (2013-08-09 14:04:15)
> Hi Chris,
>
> On Thu, 20 Jun 2013, Chris Mason wrote:
> > Quoting Sage Weil (2013-06-20 17:56:19)
> > > On Wed, 19 Jun 2013, Sage Weil wrote:
> > > > Hi Chris,
> > > >
> > > > On Tue, 18 Jun 2013, Chris Mason wrote:
> > > > > [...]
> > > > > Very long way
On Fri, Aug 09, 2013 at 02:26:36PM +0200, Andreas Schwab wrote:
> Josef Bacik writes:
>
> > So stripe_len shouldn't be 0, if it is you have bigger problems :).
>
> The bigger problem is that stripe_nr is u64, this is completely bogus.
> The first operand of do_div must be u32. This goes through
Hi Chris,
On Thu, 20 Jun 2013, Chris Mason wrote:
> Quoting Sage Weil (2013-06-20 17:56:19)
> > On Wed, 19 Jun 2013, Sage Weil wrote:
> > > Hi Chris,
> > >
> > > On Tue, 18 Jun 2013, Chris Mason wrote:
> > > > [...]
> > > > Very long way of saying I think we're one release_path short. Sage, I
>
> >Right?
>
> Yes !
> For the no option - what I like is more an intelligent way
> of listing all btrfs - mounted and unmounted by appropriately
> reading from the kernel and disks respectively.
Great!
It'll be good to get this fixed. I stumbled across this behaviour of
btrfs fi show lying
On 8/8/13 3:17 AM, Jan Schmidt wrote:
> These two patches add the announced tests for btrfs send / receive. As
> requested, the fssum tool is now included.
>
> One drawback is that I'm unable to edit configure.ac or whatever needs
> to be modified in an autotools preferred way. Any hints appreciat
On Mon, Jun 03, 2013 at 02:31:41PM +0200, Arvin Schnell wrote:
> commit 46de1a6ec3dbb0db203baa6c46cb64ba9b000ea2 changed the
> parameters of btrfs_read_and_process_send_stream(). This breaks
> snapper compilation so I wonder whether we can include version
> defines usable for the C preprocessor.
The second round uses btrfs_error() and return -EIO, the first round
can handle write errors the same way.
Signed-off-by: Stefan Behrens
---
fs/btrfs/disk-io.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c
index e76554b..d79b506
On Fri, 9 Aug 2013 14:50:35 +0100, Filipe David Manana wrote:
> On Fri, Aug 9, 2013 at 2:07 PM, Stefan Behrens
> wrote:
>> On Thu, 8 Aug 2013 21:00:52 +0100, Filipe David Borba Manana wrote:
>>> Since all code paths that update the number of devices in the
>>> super copy (fs_info->super_copy) fir
On Fri, Aug 09, 2013 at 01:47:24PM +0800, Miao Xie wrote:
> On thu, 8 Aug 2013 22:45:48 +0100, Filipe David Borba Manana wrote:
> > 8MiB is way too large and likely set by mistake. This is not
> > a significant issue as in practice the max amount of data
> > added to an inline extent is also limite
This change fixes an issue when removing a device and writing
all super blocks run simultaneously. Here's the steps necessary
for the issue to happen:
1) disk-io.c:write_all_supers() gets a number of N devices from the
super_copy, so it will not panic if it fails to write super blocks
for N
On Fri, 9 Aug 2013 16:10:39 +0200, David Sterba wrote:
> On Wed, Aug 07, 2013 at 10:17:57AM -0500, Eric Sandeen wrote:
>> And isn't it still a mistake? I think it used to be that
>> subvol_uuid_search_init()
>> would allocate the memory which must be freed, but that's no longer the case,
>> right
On Fri, Aug 09, 2013 at 02:30:38PM +0200, Andreas Schwab wrote:
> Andreas Schwab writes:
>
> > Josef Bacik writes:
> >
> >> So stripe_len shouldn't be 0, if it is you have bigger problems :).
> >
> > The bigger problem is that stripe_nr is u64, this is completely bogus.
> > The first operand of
On Wed, Aug 07, 2013 at 10:17:57AM -0500, Eric Sandeen wrote:
> And isn't it still a mistake? I think it used to be that
> subvol_uuid_search_init()
> would allocate the memory which must be freed, but that's no longer the case,
> right? So under what circumstances is it correct to call
> subvol
On Fri, Aug 9, 2013 at 2:07 PM, Stefan Behrens
wrote:
> On Thu, 8 Aug 2013 21:00:52 +0100, Filipe David Borba Manana wrote:
>> Since all code paths that update the number of devices in the
>> super copy (fs_info->super_copy) first lock the device list
>> (fs_info->fs_devices->device_list_mutex),
On Fri, Aug 9, 2013 at 12:44 AM, David Sterba wrote:
> On Wed, Aug 07, 2013 at 12:29:44PM +0100, Filipe David Borba Manana wrote:
>> Currently the compression settings (algorithm and force mode) need
>> to be specified at mount time in order to have newly created files
>> compressed.
> [...]
>
> I
On Fri, Aug 9, 2013 at 1:01 AM, David Sterba wrote:
> On Wed, Aug 07, 2013 at 12:33:09PM +0100, Filipe David Manana wrote:
>> Thanks, I missed to find that before.
>> The implementation is very different from the one I proposed.
>
> That's one of the fundaental questions how to store the informati
On Thu, 8 Aug 2013 21:00:52 +0100, Filipe David Borba Manana wrote:
> Since all code paths that update the number of devices in the
> super copy (fs_info->super_copy) first lock the device list
> (fs_info->fs_devices->device_list_mutex), and write_all_supers()
> also needs to lock the devices list
On Thu, Aug 08, 2013 at 04:35:46PM +0800, Liu Bo wrote:
> This aims to add deduplication subcommand, 'btrfs dedup command ',
> ie. register/unregister'.
I'm not sure that calling it register/unregister is the right thing, IMO
it's more enable/disable as you write in the documentation under each
re
Hello, just add my answer for a missing question.
> On Fri, 09 Aug 2013 13:56:19 +0800
> Wang Shilong wrote:
>
>>> It seems that btrfs automatically assigns a qgroup to newly created
>>> snapshot/subvolume, but does not destroy the qgroup when the
>>> subvolume is deleted.
>>
>> This should be
Andreas Schwab writes:
> Josef Bacik writes:
>
>> So stripe_len shouldn't be 0, if it is you have bigger problems :).
>
> The bigger problem is that stripe_nr is u64, this is completely bogus.
> The first operand of do_div must be u32. This goes through the whole
> file.
Of course, what I mean
Josef Bacik writes:
> So stripe_len shouldn't be 0, if it is you have bigger problems :).
The bigger problem is that stripe_nr is u64, this is completely bogus.
The first operand of do_div must be u32. This goes through the whole
file.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Ke
On 09/08/2013 02:08, Zach Brown wrote:
On Thu, Aug 08, 2013 at 04:07:07PM +0800, Anand Jain wrote:
As of now btrfs filesystem show reads directly from
disks. So sometimes output can be stale, mainly when
user want to verify their last operation like,
labeling or device delete or add... etc.
On 08/09/2013 05:42 PM, Arne Jansen wrote:
> On 07.08.2013 07:12, Wang Shilong wrote:
>> btrfs_free_qgroup_config() is not only called by open/close_ctree(),but
>> also btrfs_disable_quota().And for btrfs_disable_quota(),we have set
>> 'quota_root' to be null before calling btrfs_free_qgroup_config
On 07.08.2013 07:12, Wang Shilong wrote:
> btrfs_free_qgroup_config() is not only called by open/close_ctree(),but
> also btrfs_disable_quota().And for btrfs_disable_quota(),we have set
> 'quota_root' to be null before calling btrfs_free_qgroup_config(),so it
> is safe to cleanup in-memory structur
On 07.08.2013 07:12, Wang Shilong wrote:
> We have checked 'quota_root' with qgroup_ioctl_lock held before,So
> here the check is reduplicate, remove it.
>
> Signed-off-by: Wang Shilong
> Reviewed-by: Miao Xie
> ---
> fs/btrfs/qgroup.c | 5 -
> 1 file changed, 5 deletions(-)
>
> diff --git
On 07.08.2013 07:12, Wang Shilong wrote:
> When disabling quota, we should clear out list 'dirty_qgroups',otherwise,
> we will get oops if enabling quota again. Fix this by abstracting similar
> code from del_qgroup_rb().
>
> Signed-off-by: Wang Shilong
> Reviewed-by: Miao Xie
> ---
> fs/btrfs/
On 08/08/2013 09:20 PM, Josef Bacik wrote:
> On Wed, Aug 07, 2013 at 01:12:29PM +0800, Wang Shilong wrote:
>> When disabling quota, we should clear out list 'dirty_qgroups',otherwise,
>> we will get oops if enabling quota again. Fix this by abstracting similar
>> code from del_qgroup_rb().
>>
>> Si
The origin code dealt with 'ref' as following steps:
|->list_del(&ref-list)
|->some operations
|-->goto cleanup if failed
|->kfree(ref)
cleanup:
|->cleanup all 'ref's in the list
If operations failed, it would goto label 'cleanup' without
freeing this 'ref'.
On Fri, August 09, 2013 at 07:25 (+0200), Wang Shilong wrote:
> The origin code dealt with 'ref' as following steps:
> |->list_del(&ref-list)
> |->some operations
> |->kfree(ref)
>
> If operations failed, it would goto label 'out' without freeing this 'ref'.
> and then
On Fri, August 09, 2013 at 07:25 (+0200), Wang Shilong wrote:
> struct __prelim_ref is allocated and freed frequently when
> walking backref tree, using slab allocater can not only
> speed up allocating but also detect memory leaks.
>
> Signed-off-by: Wang Shilong
> Reviewed-by: Miao Xie
> ---
On Fri, 09 Aug 2013 14:56:15 +0800
Wang Shilong wrote:
> > So how exactly should I do it? A bit confused on how to proceed.
>
> btrfs qgroup remove 4494 13/1
>
> will destroy relation between 4494 and 13/1
> Then you can try:
>
> btrfs qgroup destroy 4494
Excellent, thanks a lot!
--
Tomas
I've been waiting for such functionality quite a long time, great to
seem some progress here :)
It would allow me to compress files which are not frequently accessed
(~75%?) with zlib, while staying at LZO for everything else.
> I think we should take the top-down approach and start with UI how to
43 matches
Mail list logo
