On 08/09/2013 02:42 PM, Tomasz Chmielewski wrote:
> On Fri, 09 Aug 2013 14:08:48 +0800
> Wang Shilong wrote:
>
>>> 0/4494 839516160 18446744073709481984 --- <-- want to remove
>>> only this one
>>>
>>> 13/1 2142674944 2142674944
>>> 0/3973,0/3974,0/3978,0/3981,0/4355,0/4373,0/4398,0/4400,0/
On Fri, 09 Aug 2013 14:08:48 +0800
Wang Shilong wrote:
> > 0/4494 839516160 18446744073709481984 --- <-- want to remove
> > only this one
> >
> > 13/1 2142674944 2142674944
> > 0/3973,0/3974,0/3978,0/3981,0/4355,0/4373,0/4398,0/4400,0/4401,0/4427,0/4448,0/4449,0/4457,0/4458,0/4475,0/4476,0
On 08/09/2013 02:07 PM, Tomasz Chmielewski wrote:
> 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 im
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 implemented. And will soon.
Great to hear (using 3.11-rc4
Hello,
On 08/09/2013 01:39 PM, Tomasz Chmielewski wrote:
> I'm using qgroups and have created a few hundreds of subvolumes in the
> past.
>
> It seems that btrfs automatically assigns a qgroup to newly created
> snapshot/subvolume, but does not destroy the qgroup when the subvolume
> is deleted.
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 limited by the page cache
> and btree leaf sizes.
I don't think 8KB is
I'm using qgroups and have created a few hundreds of subvolumes in the
past.
It seems that btrfs automatically assigns a qgroup to newly created
snapshot/subvolume, but does not destroy the qgroup when the subvolume
is deleted.
So I've tried to destroy the unused qgroups, with mixed success. I wa
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 memory leak would happen.Just move list_del() after kfree()
will fix the
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
---
V1->V2:
1.fix a missing allocating case that should be used by
kmem
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 information:
inside existing structures, via xattrs, under new tree i
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 think we should take the top-down approach and start with UI ho
Thanks for updating the license. One comment that's applicable to all
patches:
On Wed, Aug 07, 2013 at 01:54:03PM +0800, Wang Shilong wrote:
> +.SH AVAILABILITY
> +.B btrfs-debug-tree
> +is part of btrfs-progs. Btrfs is currently under heavy development,
> +and not suitable for any uses other than
On Wed, Aug 07, 2013 at 03:46:20PM +0200, Martin Steigerwald wrote:
> > Because really, the motivation sounds like it's primarily for significant
> > on-disk format changes controlled by mount options. I understand that
> > motivation more than being able to persist something like "noatime."
>
>
On Thu, Aug 08, 2013 at 10:45:48PM +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 limited by the page cache
> and btree leaf sizes.
>
> Signed-off
On Thu, Aug 08, 2013 at 09:11:01PM +0200, Arne Jansen wrote:
> On 08/08/13 19:46, Zach Brown wrote:
> >>> even though the function is currently unused, I'm hesitating to remove it
> >>> as it's part of the reada-API and might be handy for anyone going to use
> >>> the API in the future.
> >>
> >> I
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 limited by the page cache
and btree leaf sizes.
Signed-off-by: Filipe David Borba Manana
---
fs/btrfs/disk-io.c |2 +-
fs/btrfs/disk-io.h |
> I also don't know if any common use fs has an optimization whereby
> just the modified sector(s) is overwritten, rather than all sectors
> making up the file system block being modified.
Most of them do. The generic direct io path allows sector sized dio.
The very first bit of do_blockdev_direc
On Aug 8, 2013, at 2:23 PM, John Williams wrote:
>
> So I guess the reason that ZFS does well with that workload is that
> ZFS is using smaller blocks, maybe just 512B ?
Likely. It uses a variable block size.
> I wonder how common these type of non-4K aligned workloads are.
> Apparently, peop
On Thu, Jun 27, 2013 at 12:40:30AM +0200, Gabriel de Perthuis wrote:
> ---
> The matching kernel patch is here:
> https://github.com/g2p/linux/tree/v3.10%2Bextent-same (rebased on 3.10,
> fixing a small conflict)
> Requires the btrfs-extent-same command:
>
> - http://permalink.gmane.org/gmane.com
On Thu, Aug 08, 2013 at 01:23:22PM -0700, John Williams wrote:
> On Thu, Aug 8, 2013 at 12:40 PM, Josef Bacik wrote:
> > On Thu, Aug 08, 2013 at 09:13:04AM -0700, John Williams wrote:
> >> Phoronix periodically runs benchmarks on filesystems, and one thing I
> >> have noticed is that btrfs always
On Thu, Aug 8, 2013 at 12:40 PM, Josef Bacik wrote:
> On Thu, Aug 08, 2013 at 09:13:04AM -0700, John Williams wrote:
>> Phoronix periodically runs benchmarks on filesystems, and one thing I
>> have noticed is that btrfs always does terribly on their fio "Intel
>> IOMeter fileserver access pattern"
tl;dr: we got the faulty code pinned down, it's m68k specific,
except the m68k specific part didn’t change from 3.2…
Joe Perches dixit:
>Something like this maybe. (uncompiled/untested)
I tried this:
--- div64.h.orig2013-08-08 19:34:32.663540965 +
+++ - 2013-08-08 19:47:30.309776
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 mutex, make write_all_supers()
read the number of devices from the super cop
On Thu, Aug 08, 2013 at 09:13:04AM -0700, John Williams wrote:
> Phoronix periodically runs benchmarks on filesystems, and one thing I
> have noticed is that btrfs always does terribly on their fio "Intel
> IOMeter fileserver access pattern" benchmark:
>
> http://www.phoronix.com/scan.php?page=art
On 08/08/13 19:46, Zach Brown wrote:
>>> even though the function is currently unused, I'm hesitating to remove it
>>> as it's part of the reada-API and might be handy for anyone going to use
>>> the API in the future.
>>
>> I agree. As replied here,
>> http://www.mail-archive.com/linux-btrfs@vger.
> What is going on here? Why is btrfs doing so poorly?
Funny thing, I was thinking exactly the same when reading the article ;)
Regards
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vg
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.
>
> This patch adds --kernel option t
> > even though the function is currently unused, I'm hesitating to remove it
> > as it's part of the reada-API and might be handy for anyone going to use
> > the API in the future.
>
> I agree. As replied here,
> http://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg24047.html
> please keep
On 8/8/13 3:17 AM, Jan Schmidt wrote:
> Basic send / receive functionality test for btrfs. Requires current
> version of fsstress built (-x support). Relies on fssum tool but can
> skip the test if it failed to build.
>
> Signed-off-by: Jan Schmidt
> Reviewed-by: Josef Bacik
> ---
> tests/btrfs
On 8/8/13 3:17 AM, Jan Schmidt wrote:
> fssum is a tool to build a recursive checksum for a file system. The home
> repository of fssum is
>
> git://git.kernel.org/pub/scm/linux/kernel/git/arne/far-progs.git
>
> It is added as an optional target, because it depends on glibc >= 2.15 for
> SEEK
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 Thu, Aug 08, 2013 at 09:13:04AM -0700, John Williams wrote:
> Phoronix periodically runs benchmarks on filesystems, and one thing I
> have noticed is that btrfs always does terribly on their fio "Intel
> IOMeter fileserver access pattern" benchmark:
>
> http://www.phoronix.com/scan.php?page=art
Phoronix periodically runs benchmarks on filesystems, and one thing I
have noticed is that btrfs always does terribly on their fio "Intel
IOMeter fileserver access pattern" benchmark:
http://www.phoronix.com/scan.php?page=article&item=linux_310_10fs&num=2
Here, btrfs is more than 6 times slower t
On Tue, Aug 06, 2013 at 11:42:47AM -0700, Mark Fasheh wrote:
> The following series of patches implements in btrfs an ioctl to do
> out-of-band deduplication of file extents.
Reviewed-by: David Sterba
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a messa
On Thu, Aug 08, 2013 at 06:48:05AM -0700, Christoph Hellwig wrote:
> On Thu, Aug 08, 2013 at 09:02:07AM -0400, Josef Bacik wrote:
> > This won't work, try having 1 subvolumes with dirty inodes and do sync
> > then
> > go skiing, you'll have time :). Thanks,
>
> Why would the dirty inodes mak
On Thu, Aug 08, 2013 at 06:48:05AM -0700, Christoph Hellwig wrote:
> On Thu, Aug 08, 2013 at 09:02:07AM -0400, Josef Bacik wrote:
> > This won't work, try having 1 subvolumes with dirty inodes and do sync
> > then
> > go skiing, you'll have time :). Thanks,
>
> Why would the dirty inodes mak
On Thu, August 08, 2013 at 16:28 (+0200), David Sterba wrote:
> On Thu, Aug 08, 2013 at 09:36:52AM +0200, Jan Schmidt wrote:
>> Weird patch formatting concerning extent_io.c, I assume there are no changes
>> in
>> extent_buffer_under_io and btrfs_release_extent_buffer_page, you just moved
>> btrfs
On Thu, Aug 08, 2013 at 09:36:52AM +0200, Jan Schmidt wrote:
> Weird patch formatting concerning extent_io.c, I assume there are no changes
> in
> extent_buffer_under_io and btrfs_release_extent_buffer_page, you just moved
> btrfs_clone_extent_buffer, right? Perhaps --patience or --minimal could d
On Thu, Aug 08, 2013 at 01:04:19PM +0800, 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 Thu, Aug 08, 2013 at 12:43:23AM +0300, Sergei Trofimovich wrote:
> From: Sergei Trofimovich
>
> Found by uselex.rb:
> > btrfs_get_inode_ref_index: [R]: exported from: fs/btrfs/inode-item.o
> > fs/btrfs/btrfs.o fs/btrfs/built-in.o
>
> Signed-off-by: Sergei Trofimovich
Safe to remove.
Revie
On Thu, Aug 08, 2013 at 09:02:07AM -0400, Josef Bacik wrote:
> This won't work, try having 1 subvolumes with dirty inodes and do sync
> then
> go skiing, you'll have time :). Thanks,
Why would the dirty inodes make any difference? If you share the bdi
between the subvolumes the sync workflo
On Thu, Aug 08, 2013 at 12:43:19AM +0300, Sergei Trofimovich wrote:
> From: Sergei Trofimovich
>
> Found by uselex.rb:
> > btrfs_write_and_wait_marked_extents: [R]: exported from: fs/btrfs/btrfs.o
> > fs/btrfs/transaction.o fs/btrfs/built-in.o
>
> Signed-off-by: Sergei Trofimovich
> ---
> fs/
On Thu, Aug 08, 2013 at 12:43:20AM +0300, Sergei Trofimovich wrote:
> From: Sergei Trofimovich
>
> Found by uselex.rb:
> > btrfs_start_transaction_lflush: [R]: exported from: fs/btrfs/btrfs.o
> > fs/btrfs/transaction.o fs/btrfs/built-in.o
http://www.mail-archive.com/linux-btrfs@vger.kernel.org/
On Thu, Aug 08, 2013 at 09:33:14AM +0200, Arne Jansen wrote:
> On 07.08.2013 23:43, Sergei Trofimovich wrote:
> > From: Sergei Trofimovich
> >
> > Found by uselex.rb:
> >> btrfs_reada_detach: [R]: exported from: fs/btrfs/btrfs.o
> >> fs/btrfs/built-in.o fs/btrfs/reada.o
>
> even though the func
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().
>
> Signed-off-by: Wang Shilong
> Reviewed-by: Miao Xi
On Thu, August 08, 2013 at 15:12 (+0200), Josef Bacik wrote:
> On Thu, Aug 08, 2013 at 09:23:06AM +0200, Jan Schmidt wrote:
>>
>> On Wed, August 07, 2013 at 23:11 (+0200), Josef Bacik wrote:
>>> There is no reason we can't just set the path to blocking and then do normal
>>> GFP_NOFS allocations
On Thu, Aug 08, 2013 at 09:23:06AM +0200, Jan Schmidt wrote:
>
> On Wed, August 07, 2013 at 23:11 (+0200), Josef Bacik wrote:
> > There is no reason we can't just set the path to blocking and then do normal
> > GFP_NOFS allocations for these extent buffers. Thanks,
> >
> > Signed-off-by: Josef
On Thu, Aug 08, 2013 at 09:36:52AM +0200, Jan Schmidt wrote:
> On Wed, August 07, 2013 at 23:03 (+0200), Josef Bacik wrote:
> > We can get ENOMEM trying to allocate dummy bufs for the rewind operation of
> > the
> > tree mod log. Instead of BUG_ON()'ing in this case pass up ENOMEM. I
> > looked
On Thu, Aug 08, 2013 at 05:13:49AM -0700, Christoph Hellwig wrote:
> On Wed, Aug 07, 2013 at 04:51:46PM -0400, Josef Bacik wrote:
> > Not possible, this will break other things as subvolumes have their own
> > inode
> > space, it will confuse applications that get multiples of an inode number
> >
On Wed, Aug 07, 2013 at 04:51:46PM -0400, Josef Bacik wrote:
> Not possible, this will break other things as subvolumes have their own inode
> space, it will confuse applications that get multiples of an inode number for
> different devices with the same st_dev. Each subvolume has it's own anonymo
> On Thu, August 08, 2013 at 07:04 (+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 Thu, August 08, 2013 at 07:04 (+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 08/08/2013 07:02 PM, Jan Schmidt wrote:
>
> On Thu, August 08, 2013 at 07:04 (+0200), Wang Shilong wrote:
>> Signed-off-by: Wang Shilong
>> Reviewed-by: Miao Xie
>> ---
>> fs/btrfs/backref.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/fs/btrfs/backref.c b/fs/
On 08/08/2013 06:24 PM, Filipe David Manana wrote:
> On Thu, Aug 8, 2013 at 6:04 AM, Wang Shilong
> wrote:
>> find_extent_in_eb() may return ENOMEM, catch this error return value.
>>
>> Signed-off-by: Wang Shilong
>> Reviewed-by: Miao Xie
>> ---
>> fs/btrfs/backref.c | 4
>> 1 file change
On Thu, August 08, 2013 at 12:24 (+0200), Filipe David Manana wrote:
> On Thu, Aug 8, 2013 at 6:04 AM, Wang Shilong
> wrote:
>> find_extent_in_eb() may return ENOMEM, catch this error return value.
>>
>> Signed-off-by: Wang Shilong
>> Reviewed-by: Miao Xie
>> ---
>> fs/btrfs/backref.c | 4 ++
On Fri, 02 Aug 2013 20:24:55 -0500, Eric Sandeen wrote:
> cmds-recieve.c & cmds-send.c seem to have weird wrappers and
> indirections, and "groups" of commands which have only
> one member, which are never referenced in the code.
>
> I think these can be removed.
>
> Signed-off-by: Eric Sandeen
On Thu, August 08, 2013 at 07:04 (+0200), Wang Shilong wrote:
> Signed-off-by: Wang Shilong
> Reviewed-by: Miao Xie
> ---
> fs/btrfs/backref.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/btrfs/backref.c b/fs/btrfs/backref.c
> index cb73a12..54e7610 100644
> ---
On Thu, Aug 8, 2013 at 11:52 AM, Stefan Behrens
wrote:
> On Thu, 4 Jul 2013 10:48:39 +0100, Filipe David Borba Manana wrote:
>> Instead of aborting with a BUG_ON() statement, return a
>> negated errno code. Also updated mkfs and convert tools
>> to print a nicer error message when make_btrfs() re
On Thu, Aug 8, 2013 at 11:51 AM, Stefan Behrens
wrote:
> Commit 55061a98 adds a cut & paste error that makes mkfs.btrfs fail
> if leafsize != sectorsize.
>
> Signed-off-by: Stefan Behrens
> ---
> utils.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/utils.c b/utils.c
>
On Thu, 4 Jul 2013 10:48:39 +0100, Filipe David Borba Manana wrote:
> Instead of aborting with a BUG_ON() statement, return a
> negated errno code. Also updated mkfs and convert tools
> to print a nicer error message when make_btrfs() returns
> an error.
>
> Signed-off-by: Filipe David Borba Mana
Commit 55061a98 adds a cut & paste error that makes mkfs.btrfs fail
if leafsize != sectorsize.
Signed-off-by: Stefan Behrens
---
utils.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/utils.c b/utils.c
index 15b991f..691b075 100644
--- a/utils.c
+++ b/utils.c
@@ -430,7 +430,
On Thu, Aug 8, 2013 at 6:04 AM, Wang Shilong wrote:
> find_extent_in_eb() may return ENOMEM, catch this error return value.
>
> Signed-off-by: Wang Shilong
> Reviewed-by: Miao Xie
> ---
> fs/btrfs/backref.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/fs/btrfs/backref.c b/fs/btr
While removing a file with dedup extents, we could have a great number of
delayed refs pending to process, and these refs refer to droping
a ref of the extent, which is of BTRFS_DROP_DELAYED_REF type.
But in order to prevent an extent's ref count from going down to zero when
there still are pendin
This aims to add deduplication subcommand, 'btrfs dedup command ',
ie. register/unregister'.
It can be used to enable or disable dedup support for a filesystem.
Signed-off-by: Liu Bo
---
v2: add manpage
Makefile |2 +-
btrfs.c|1 +
cmds-dedup.c | 101 ++
It's unnecessary to do qgroups accounting without enabling quota.
Signed-off-by: Liu Bo
---
v6:
* don't record seq for qgroups with quota disabled as we do not need to,
and keep the checker of qgroups.
fs/btrfs/ctree.c |2 +-
fs/btrfs/delayed-ref.c | 18 ++
fs/btrf
Data deduplication is a specialized data compression technique for eliminating
duplicate copies of repeating data.[1]
This patch set is also related to "Content based storage" in project ideas[2].
PATCH 1 is a hang fix with deduplication on, but it's also useful without
dedup in practice use.
PA
When we have data deduplication on, we'll hang on the merge part
because it needs to verify every queued delayed data refs related to
this disk offset but we may have millions refs.
And in the case of delayed data refs, we don't usually have too much
data refs to merge.
So it's safe to shut it do
The way how we process delayed refs is
1) get a bunch of head refs,
2) pick up one head ref,
3) go one node back for any delayed ref updates.
The head ref is also linked in the same rbtree as the delayed ref is,
so in 1) stage, we have to walk one by one including not only head refs, but
delayed r
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 appreciated,
preferrably hints containing all the modific
Basic send / receive functionality test for btrfs. Requires current
version of fsstress built (-x support). Relies on fssum tool but can
skip the test if it failed to build.
Signed-off-by: Jan Schmidt
Reviewed-by: Josef Bacik
---
tests/btrfs/316 | 113 ++
fssum is a tool to build a recursive checksum for a file system. The home
repository of fssum is
git://git.kernel.org/pub/scm/linux/kernel/git/arne/far-progs.git
It is added as an optional target, because it depends on glibc >= 2.15 for
SEEK_HOLE / SEEK_DATA. The test to be added using fssum
Oh., I missed the libblkid part of David recommendation.
I will be rewriting this patch set. sorry about that.
Thanks, Anand
On 08/08/2013 16:09, Anand Jain wrote:
This patch brings the /dev/mapper to be used as the path for
the btrfs kernel through dev scan
1/2 is the preparatory patch
An
Currently, btrsf fi show and btrfs dev scan uses
/proc/partitions (by default) (which gives priority
to dm- over sd paths) and with --all-devices it
will scan /dev only (where it skips links under /dev/mapper).
However using /dev/mapper paths are in common practice
with mount, fstab, and lvm, so i
This patch brings the /dev/mapper to be used as the path for
the btrfs kernel through dev scan
1/2 is the preparatory patch
Anand Jain (2):
btrfs-progs: btrfs_scan_one_dir not to skip links when /dev/mapper is
provided
btrfs-progs: scan /dev/mapper in filesystem show and device scan
cmds
This is preparatory work to introduce /dev/mapper path usage
we need btrfs_scan_one_dir to san devs under /dev/mapper,
but /dev/mapper has links to the actual devs and current implementation
of btrfs_scan_one_dir skips links so it does not pick any
dev under /dev/mapper. skip the links are fine wh
This patch set introduces --kernel option for filesystem show
for the reason as mentioned in the patch 1/2 below
1/1 is the preparatory patch
Anand Jain (2):
btrfs-progs: move out print in cmd_df to another function
btrfs-progs: introduce btrfs filesystem show --kernel
cmds-filesystem.c | 3
This is a prepatory work for the following btrfs fi show command
fixes. So that we have a function get_df to get the fs sizes
v2:
combined the other patches as below and rebase
btrfs-progs: get string for the group profile and type
Signed-off-by: Anand Jain
---
cmds-filesystem.c | 190
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.
This patch adds --kernel option to the 'filesystem show'
subcli, which will read from the kernel instead
On Tue, August 06, 2013 at 04:29 (+0200), Wang Shilong wrote:
> Currently, only add_delayed_refs have to allocate with GFP_ATOMIC,
> So just pass arg 'gfp_t' to decide which allocation mode.
>
> Signed-off-by: Wang Shilong
> Reviewed-by: Miao Xie
> ---
> fs/btrfs/backref.c | 30 +++-
On Wed, August 07, 2013 at 23:03 (+0200), Josef Bacik wrote:
> We can get ENOMEM trying to allocate dummy bufs for the rewind operation of
> the
> tree mod log. Instead of BUG_ON()'ing in this case pass up ENOMEM. I looked
> back through the callers and I'm pretty sure I got everybody who did
>
On 07.08.2013 23:43, Sergei Trofimovich wrote:
> From: Sergei Trofimovich
>
> Found by uselex.rb:
>> btrfs_reada_detach: [R]: exported from: fs/btrfs/btrfs.o fs/btrfs/built-in.o
>> fs/btrfs/reada.o
even though the function is currently unused, I'm hesitating to remove it
as it's part of the rea
On Wed, August 07, 2013 at 23:11 (+0200), Josef Bacik wrote:
> There is no reason we can't just set the path to blocking and then do normal
> GFP_NOFS allocations for these extent buffers. Thanks,
>
> Signed-off-by: Josef Bacik
> ---
> fs/btrfs/ctree.c | 16 ++--
> fs/btrfs/
82 matches
Mail list logo
