Re: degraded permanent mount option

On Mon, Jan 29, 2018 at 14:00:53 -0500, Austin S. Hemmelgarn wrote: > We already do so in the accepted standard manner. If the mount fails > because of a missing device, you get a very specific message in the > kernel log about it, as is the case for most other common errors (for > uncommon

Re: degraded permanent mount option

On Mon, Jan 29, 2018 at 21:44:23 -0700, Chris Murphy wrote: > Btrfs is orthogonal to systemd's willingness to wait forever while > making no progress. It doesn't matter what it is, it shouldn't wait > forever. It times out after 90 seconds (by default) and then it fails the mount entirely. > It

Re: [PATCH v2] btrfs: Add chunk allocation ENOSPC debug message for enospc_debug mount option

On Mon, Jan 22, 2018 at 10:11:44AM +0200, Nikolay Borisov wrote: > > @@ -4731,6 +4740,12 @@ static int __btrfs_alloc_chunk(struct > > btrfs_trans_handle *trans, > > > > if (ndevs < devs_increment * sub_stripes || ndevs < devs_min) { > > ret = -ENOSPC; > > + if

Re: [PATCH v3] btrfs: Ignore errors from btrfs_qgroup_trace_extent_post

On Mon, Jan 29, 2018 at 10:06:52PM +0800, Qu Wenruo wrote: > > > On 2018年01月29日 21:53, Nikolay Borisov wrote: > > Running generic/019 with qgroups on the scratch device enabled is > > almost guaranteed to trigger the BUG_ON in btrfs_free_tree_block. It's > > supposed to trigger only on -ENOMEM,

[RESEND PATCH] btrfs: Handle btrfs_set_extent_delalloc failure in relocate_file_extent_cluster

Essentially duplicate the error handling from the above block which handles the !PageUptodate(page) case and additionally clear EXTENT_BOUNDARY. Signed-off-by: Nikolay Borisov Reviewed-by: Josef Bacik --- Put description of the intended changes.

Re: [PATCH] Btrfs: fix unexpected cow in run_delalloc_nocow

On Thu, Jan 25, 2018 at 11:02:49AM -0700, Liu Bo wrote: > Fstests generic/475 provides a way to fail metadata reads while > checking if checksum exists for the inode inside run_delalloc_nocow(), > and csum_exist_in_range() interprets error (-EIO) as inode having > checksum and makes its caller

Re: degraded permanent mount option

On Mon, Jan 29, 2018 at 08:42:32 -0500, Austin S. Hemmelgarn wrote: >> Yes. They are stupid enough to fail miserably with any more complicated >> setups, like stacking volume managers, crypto layer, network attached >> storage etc. > I think you mean any setup that isn't sensibly layered. No, I

Re: [PATCH] btrfs: tree-checker: Replace root parameter with fs_info

On Fri, Jan 26, 2018 at 09:31:06AM -0500, Josef Bacik wrote: > On Thu, Jan 25, 2018 at 02:56:18PM +0800, Qu Wenruo wrote: > > When inspecting the error message with real corruption, the "root=%llu" > > always shows "1" (root tree), instead of correct owner. > > > > The problem is that we are

Re: degraded permanent mount option

On 2018-01-30 08:46, Tomasz Pala wrote: On Mon, Jan 29, 2018 at 08:05:42 -0500, Austin S. Hemmelgarn wrote: Seriously, _THERE IS A RACE CONDITION IN SYSTEMD'S CURRENT HANDLING OF THIS_. It's functionally no different than prefacing an attempt to send a signal to a process by checking if the

Re: [PATCH] btrfs: Streamline btrfs_delalloc_reserve_metadata initial operations

On 30.01.2018 16:34, David Sterba wrote: > On Fri, Jan 12, 2018 at 04:21:05PM +0200, Nikolay Borisov wrote: >> @@ -6062,19 +6062,19 @@ int btrfs_delalloc_reserve_metadata(struct >> btrfs_inode *inode, u64 num_bytes) >> * If we have a transaction open (can happen if we call truncate_block

Re: [PATCH] btrfs: Streamline btrfs_delalloc_reserve_metadata initial operations

On Fri, Jan 12, 2018 at 04:21:05PM +0200, Nikolay Borisov wrote: > @@ -6062,19 +6062,19 @@ int btrfs_delalloc_reserve_metadata(struct > btrfs_inode *inode, u64 num_bytes) >* If we have a transaction open (can happen if we call truncate_block >* from truncate), then we need

Re: degraded permanent mount option

On Tue, Jan 30, 2018 at 10:05:34 -0500, Austin S. Hemmelgarn wrote: >> Instead, they should move their legs continuously and if the train is > not >> on the station yet, just climb back and retry. > No, that's really not a good analogy given the fact that that check for > the presence of a

Re: [GIT PULL] inode->i_version rework for v4.16

On Tue, Jan 30, 2018 at 07:05:48AM -0500, Jeff Layton wrote: > > I want to make sure I understand what's actually broken here thoug. Is > it only broken when the two values are more than 2**63 apart, or is > there something else more fundamentally wrong here? The other problem is that returning

[RESEND PATCH] btrfs: Fix UAF when cleaning up fs_devs with a single stale device

Commit 4fde46f0cc71 ("Btrfs: free the stale device") introduced btrfs_free_stale_device which iterates the device lists for all registered btrfs filesystems and deletes those devices which aren't mounted. In a btrfs_devices structure has only 1 device attached to it and it is unused then

Re: [PATCH v2 0/2] fix device orders consistency

On Mon, Jan 22, 2018 at 02:49:35PM -0800, Anand Jain wrote: > Could you pls consider this for 4.16 ? Sorry, the patches are not fixes and I'll probably not add them to 4.16 and they missed the first pull. But I will add them to misc-next so they still help debugging and any fix that you come up

Re: [PATCH] btrfs: Use schedule_timeout_interruptible

On Wed, Jan 24, 2018 at 10:38:51AM -0500, Josef Bacik wrote: > On Tue, Jan 23, 2018 at 02:46:53PM +0200, Nikolay Borisov wrote: > > Instead of manually fiddling with the state of the task > > (RUNNING->INTERRUPTIBLE->RUNNING) again just use > > schedule_timeout_interruptible > > which adjusts the

Re: degraded permanent mount option

On 2018-01-30 10:09, Tomasz Pala wrote: On Mon, Jan 29, 2018 at 08:42:32 -0500, Austin S. Hemmelgarn wrote: Yes. They are stupid enough to fail miserably with any more complicated setups, like stacking volume managers, crypto layer, network attached storage etc. I think you mean any setup

[PATCH] Btrfs: fix null pointer dereference when replacing missing device

From: Filipe Manana When we are replacing a missing device we mount the filesystem with the degraded mode option in which case we are allowed to have a btrfs device structure without a backing device member (its bdev member is NULL) and therefore we can't dereference that

Re: degraded permanent mount option

On Tue, Jan 30, 2018 at 16:09:50 +0100, Tomasz Pala wrote: >> BCP for over a >> decade has been to put multipathing at the bottom, then crypto, then >> software RAID, than LVM, and then whatever filesystem you're using. > > Really? Let's enumerate some caveats of this: > > - crypto below

Re: [PATCH] iversion: make inode_cmp_iversion{+raw} return bool instead of s64

On Tue, 2018-01-30 at 12:31 -0500, Jeff Layton wrote: > From: Jeff Layton > > As Linus points out: > > The inode_cmp_iversion{+raw}() functions are pure and utter crap. > > Why? > > You say that they return 0/negative/positive, but they do so in a >

Re: [GIT PULL] inode->i_version rework for v4.16

On Tue, Jan 30, 2018 at 4:05 AM, Jeff Layton wrote: > > My intent here was to have this handle wraparound using the same sort of > method that the time_before/time_after macros do. Obviously, I didn't > document that well. Oh, the intent was clear. The implementation was

Re: [GIT PULL] inode->i_version rework for v4.16

On Mon, 2018-01-29 at 13:50 -0800, Linus Torvalds wrote: > On Mon, Jan 29, 2018 at 4:26 AM, Jeff Layton wrote: > > > > This pile of patches is a rework of the inode->i_version field. We have > > traditionally incremented that field on every inode data or metadata > > change.

Re: degraded permanent mount option

On Mon, Jan 29, 2018 at 08:05:42 -0500, Austin S. Hemmelgarn wrote: > Seriously, _THERE IS A RACE CONDITION IN SYSTEMD'S CURRENT HANDLING OF > THIS_. It's functionally no different than prefacing an attempt to send > a signal to a process by checking if the process exists, or trying to > see

Re: degraded permanent mount option

On 2018-01-29 16:54, waxhead wrote: Austin S. Hemmelgarn wrote: On 2018-01-29 12:58, Andrei Borzenkov wrote: 29.01.2018 14:24, Adam Borowski пишет: ... So any event (the user's request) has already happened.  A rc system, of which systemd is one, knows whether we reached the "want root

Re: [PATCH v2 1/2] btrfs: fix device order consistency

On Mon, Jan 22, 2018 at 02:49:36PM -0800, Anand Jain wrote: > By maintaining the device order consistency it makes reproducing > the problems related to missing chunk in the degraded mode much more > consistent. So fix this by sorting the devices by devid within the > kernel. So that we know which

Re: degraded permanent mount option

On Tue, Jan 30, 2018 at 08:46:32 -0500, Austin S. Hemmelgarn wrote: >> I personally think the degraded mount option is a mistake as this >> assumes that a lightly degraded system is not able to work which is false. >> If the system can mount to some working state then it should mount >>

Re: btrfs check: backref lost, mismatch with its hash -- can't repair

Finally restored by merging the last snapshot with what btrfs restore gave me -- surprisingly almost the whole bunch of it :-) Thanks for helping! Cheers, Marco Qu Wenruo wrote on 2018-01-30 02:24: > > > On 2018年01月30日 02:16, ^m'e wrote: >> Thanks! >> >> Got these >> >> # ./btrfs.static

Re: [PATCH v2] iversion: make inode_cmp_iversion{+raw} return bool instead of s64

Ack. Should I expect this in a future pull request, or take it directly? There's no hurry about this, since none of the existing users of that function actually do anything but test the return value against zero, and nobody saves it into anything but a "bool" (which has magical casting properties

Re: degraded permanent mount option

On 2018-01-30 14:50, Tomasz Pala wrote: On Tue, Jan 30, 2018 at 08:46:32 -0500, Austin S. Hemmelgarn wrote: I personally think the degraded mount option is a mistake as this assumes that a lightly degraded system is not able to work which is false. If the system can mount to some working state

Re: degraded permanent mount option

On Tue, Jan 30, 2018 at 11:30:31 -0500, Austin S. Hemmelgarn wrote: >> - crypto below software RAID means double-encryption (wasted CPU), > It also means you leak no information about your storage stack. If JBOD > you're sufficiently worried about data protection that you're using >

[PATCH v2] iversion: make inode_cmp_iversion{+raw} return bool instead of s64

From: Jeff Layton As Linus points out: The inode_cmp_iversion{+raw}() functions are pure and utter crap. Why? You say that they return 0/negative/positive, but they do so in a completely broken manner. They return that ternary value as the sequence

Re: [PATCH] iversion: make inode_cmp_iversion{+raw} return bool instead of s64

On Tue, 2018-01-30 at 17:50 +, Trond Myklebust wrote: > On Tue, 2018-01-30 at 12:31 -0500, Jeff Layton wrote: > > From: Jeff Layton > > > > As Linus points out: > > > > The inode_cmp_iversion{+raw}() functions are pure and utter crap. > > > > Why? > > > >

Re: degraded permanent mount option

Just one final word, as all was already said: On Tue, Jan 30, 2018 at 11:30:31 -0500, Austin S. Hemmelgarn wrote: >> In other words, is it: >> - the systemd that threats btrfs WORSE than distributed filesystems, OR >> - btrfs that requires from systemd to be threaded BETTER than other fss? > Or

Re: [PATCH 2/2] btrfs: drop optimal argument from find_live_mirror()

On 30.01.2018 08:28, Anand Jain wrote: > Drop optimal argument from the function find_live_mirror() > as we can deduce it in the function itself. > > Signed-off-by: Anand Jain > --- > fs/btrfs/volumes.c | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) >

[PATCH v2] btrfs: print error if primary super block write fails

Presently, failing a primary super block write but succeeding in at least one super block write in general will appear to users as if nothing important went wrong. However, upon unmounting and re-mounting, the file system will be in a rolled back state. This was discovered with a BCC program that

[PATCH] btrfs: volumes: Remove the meaningless condition of minimal nr_devs when allocating a chunk

When checking the minimal nr_devs, there is one dead and meaningless condition: if (ndevs < devs_increment * sub_stripes || ndevs < devs_min) { This condition is meaningless, @devs_increment has nothing to do with @sub_stripes. In fact, in

Re: [PATCH] btrfs: volumes: Cleanup stripe size calculation

On 31.01.2018 08:16, Qu Wenruo wrote: > Cleanup the following things: > 1) open coded SZ_16M round up > 2) use min() to replace open-coded size comparison > 3) code style > > Signed-off-by: Qu Wenruo Reviewed-by: Nikolay Borisov > --- > fs/btrfs/volumes.c

[PATCH] btrfs: volumes: Cleanup stripe size calculation

Cleanup the following things: 1) open coded SZ_16M round up 2) use min() to replace open-coded size comparison 3) code style Signed-off-by: Qu Wenruo --- fs/btrfs/volumes.c | 11 +-- 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/fs/btrfs/volumes.c

Re: [PATCH v3 0/2] fix device orders consistency

On 31.01.2018 04:28, Anand Jain wrote: > v3->v2: > rename device_sort() to device_cmp(). > v1->v2: > No code change. Change log updated to include the type > of problem that this consistency would help. And > I don't see patch 2/2 in the ML. So trying to resend. > > By maintaining the

Re: [PATCH] btrfs: volumes: Remove the meaningless condition of minimal nr_devs when allocating a chunk

On 31.01.2018 07:56, Qu Wenruo wrote: > When checking the minimal nr_devs, there is one dead and meaningless > condition: > > if (ndevs < devs_increment * sub_stripes || ndevs < devs_min) { > > > This condition is meaningless, @devs_increment has

Re: [PATCH 0/2] Policy to balance read across mirrored devices

A little question about mount -o read_mirror_policy=. How would this work with RAID1 over 3 or 4 HDD's? In particular, if the desired block is not available on device . Could i repeat this option like the device-option to specify a order/priority like this: mount -o read_mirror_policy=

Re: [PATCH v2] btrfs: print error if primary super block write fails

On 2018年01月31日 06:33, Howard McLauchlan wrote: > Presently, failing a primary super block write but succeeding in at > least one super block write in general will appear to users as if > nothing important went wrong. However, upon unmounting and re-mounting, > the file system will be in a rolled

Re: [PATCH v2 1/2] btrfs: fix device order consistency

+static int device_sort(void *priv, struct list_head *a, struct list_head *b) I'll rename that to devid_cmp as it's the comparator and not really a sorting function. Ok. I will make that change in v3. Thanks, Anand -- To unsubscribe from this list: send the line "unsubscribe

[PATCH v3 1/2] btrfs: fix device order consistency

By maintaining the device order consistency it makes reproducing the problems related to missing chunk in the degraded mode much more consistent. So fix this by sorting the devices by devid within the kernel. So that we know which device is assigned to the struct fs_info::latest_bdev when all the

[PATCH v3 0/2] fix device orders consistency

v3->v2: rename device_sort() to device_cmp(). v1->v2: No code change. Change log updated to include the type of problem that this consistency would help. And I don't see patch 2/2 in the ML. So trying to resend. By maintaining the device order (some) consistency it makes reproducing the

[PATCH] btrfs-progs: fsck-tests: Rename tree-reloc-tree test number

There are 2 fsck tests with the same number 027: tree-reloc-tree bad-extent-inline-ref-type And we also have a hole in 015, so just rename tree-reloc-tree to 015, to get rid of the duplicated test number and fill in the hole. Signed-off-by: Qu Wenruo --- .../{027-tree-reloc-tree

[PATCH v3 4/7] btrfs-progs: Use fs_info instead of root for BTRFS_MAX_XATTR_SIZE

Do a cleanup. Also make it consistent with kernel. Use fs_info instead of root for BTRFS_MAX_XATTR_SIZE, since maybe in some situation we do not know root, but just know fs_info. Changelog: v2->v1: To be consistent with kernel, change macro to inline function. Signed-off-by: Gu Jinxiang

[PATCH v3 6/7] btrfs-progs: remove no longer be used btrfs_alloc_extent

Do a cleanup. Function btrfs_alloc_extent is no longer be used. So let's remove it. Signed-off-by: Gu Jinxiang Reviewed-by: Qu Wenruo --- ctree.h | 6 -- 1 file changed, 6 deletions(-) diff --git a/ctree.h b/ctree.h index 679bbc9..41b14b5 100644 ---

[PATCH v3 0/7] btrfs-progs: Do some clean up to be consistent with kernel

Patch 1~4 and 7: clean up use of btrfs_root. Beside it, syncs code with kernel. Patch 5: remove redundancy value assignment. Patch 6: remove no longer be used function define. Changelog: v2->v1: Patch 2,4: To be consistent with kernel, change macro to inline function. Patch 3:

[PATCH v3 2/7] btrfs-progs: Use fs_info instead of root for BTRFS_NODEPTRS_PER_BLOCK

Do a cleanup. Also make it consistent with kernel. Use fs_info instead of root for BTRFS_NODEPTRS_PER_BLOCK, since maybe in some situation we do not know root, but just know fs_info. Changelog: v2->v1: To be consistent with kernel, change macro to inline function. Signed-off-by: Gu Jinxiang

[PATCH v3 1/7] btrfs-progs: Use fs_info instead of root for BTRFS_LEAF_DATA_SIZE

Do a cleanup. Also make it consistent with kernel. Use fs_info instead of root for BTRFS_LEAF_DATA_SIZE, since maybe in some situation we do not know root, but just know fs_info. Signed-off-by: Gu Jinxiang Reviewed-by: Qu Wenruo --- cmds-check.c

[PATCH v3 5/7] btrfs-progs: do clean up for redundancy value assignment

Although skinny_metadata's type is int, its value just can be 0/1. And if condition be true only when skinny_metadata equals 1, so in if's executive part, set skinny_metadata to 1 is redundancy. Remove it. Signed-off-by: Gu Jinxiang Reviewed-by: Qu Wenruo ---

[PATCH v3 7/7] btrfs-progs: Cleanup use of root in leaf_data_end

In function leaf_data_end, root is just used to get fs_info, so change the parameter of this function from btrfs_root to btrfs_fs_info. And also make it consistent with kernel. Changelog: v3->v2: Add const to parameter leaf of function btrfs_item_offset_nr to keep type consistent with

[PATCH v3 3/7] btrfs-progs: Sync code with kernel for BTRFS_MAX_INLINE_DATA_SIZE

Do a cleanup. Also make it consistent with kernel. Use fs_info instead of root for BTRFS_MAX_INLINE_DATA_SIZE, since maybe in some situation we do not know root, but just know fs_info. Changelog: v2->v1: Change macro to inline function to be consistent with kernel. And change the function body to

Re: [PATCH] Btrfs: fix null pointer dereference when replacing missing device

On 01/31/2018 02:40 AM, fdman...@kernel.org wrote: From: Filipe Manana When we are replacing a missing device we mount the filesystem with the degraded mode option in which case we are allowed to have a btrfs device structure without a backing device member (its bdev

[PATCH v3 2/2] btrfs: fix alloc device order consistency

Add opened device to the tail of dev_alloc_list instead of head, so that it maintains the same order as dev_list. Signed-off-by: Anand Jain --- fs/btrfs/volumes.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c

Re: [PATCH 2/2] btrfs: drop optimal argument from find_live_mirror()

On 01/30/2018 05:12 PM, Nikolay Borisov wrote: On 30.01.2018 08:28, Anand Jain wrote: Drop optimal argument from the function find_live_mirror() as we can deduce it in the function itself. Signed-off-by: Anand Jain --- fs/btrfs/volumes.c | 8 1 file

Re: [PATCH 2/3] btrfs: Unexport get_block_group_index()

On 2018年01月30日 16:18, Nikolay Borisov wrote: > > > On 30.01.2018 09:40, Qu Wenruo wrote: >> That function is only used inside extent-tree.c. >> >> Signed-off-by: Qu Wenruo >> --- >> fs/btrfs/ctree.h | 1 - >> fs/btrfs/extent-tree.c | 3 ++- >> 2 files changed, 2

Re: [PATCH 1/3] btrfs: Refactor __get_raid_index() to btrfs_bg_flags_to_raid_index()

On 2018年01月30日 16:16, Nikolay Borisov wrote: > > > On 30.01.2018 09:40, Qu Wenruo wrote: >> Function __get_raid_index() is used to convert block group flags into >> raid index, which can be used to get various info directly from >> btrfs_raid_array[]. >> >> Refactor this function a little: >>

[PATCH v2 2/2] btrfs: Refactor parameter of BTRFS_MAX_DEVS() from root to fs_info

Signed-off-by: Qu Wenruo Reviewed-by: Anand Jain Reviewed-by: Nikolay Borisov --- v2: Added tags. --- fs/btrfs/volumes.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c

[PATCH v2 1/2] btrfs: Refactor __get_raid_index() to btrfs_bg_flags_to_raid_index()

Function __get_raid_index() is used to convert block group flags into raid index, which can be used to get various info directly from btrfs_raid_array[]. Refactor this function a little: 1) Rename to btrfs_bg_flags_to_raid_index() Double underline prefix is normally for internal functions,

Re: [PATCH 1/3] btrfs: Refactor __get_raid_index() to btrfs_bg_flags_to_raid_index()

On 01/30/2018 03:40 PM, Qu Wenruo wrote: Function __get_raid_index() is used to convert block group flags into raid index, which can be used to get various info directly from btrfs_raid_array[]. Refactor this function a little: 1) Rename to btrfs_bg_flags_to_raid_index() Double underline

Re: [PATCH 2/3] btrfs: Unexport get_block_group_index()

diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c index e9c31b567a9c..6e1128aa29d6 100644 --- a/fs/btrfs/extent-tree.c +++ b/fs/btrfs/extent-tree.c @@ -7346,7 +7346,8 @@ wait_block_group_cache_done(struct btrfs_block_group_cache *cache) return ret; } -int

Re: [PATCH 1/3] btrfs: Refactor __get_raid_index() to btrfs_bg_flags_to_raid_index()

On 30.01.2018 09:40, Qu Wenruo wrote: > Function __get_raid_index() is used to convert block group flags into > raid index, which can be used to get various info directly from > btrfs_raid_array[]. > > Refactor this function a little: > > 1) Rename to btrfs_bg_flags_to_raid_index() >Double

Re: [PATCH 3/3] btrfs: Refactor parameter of BTRFS_MAX_DEVS() from root to fs_info

On 01/30/2018 03:40 PM, Qu Wenruo wrote: Signed-off-by: Qu Wenruo Reviewed-by: Anand Jain Thanks, Anand --- fs/btrfs/volumes.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c index

Re: [PATCH 2/3] btrfs: Unexport get_block_group_index()

On 30.01.2018 09:40, Qu Wenruo wrote: > That function is only used inside extent-tree.c. > > Signed-off-by: Qu Wenruo > --- > fs/btrfs/ctree.h | 1 - > fs/btrfs/extent-tree.c | 3 ++- > 2 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/fs/btrfs/ctree.h

Re: [PATCH 3/3] btrfs: Refactor parameter of BTRFS_MAX_DEVS() from root to fs_info

On 30.01.2018 09:40, Qu Wenruo wrote: > Signed-off-by: Qu Wenruo Reviewed-by: Nikolay Borisov > --- > fs/btrfs/volumes.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c > index

umount btrfs hang

Hi all, While trying umount a single btrfs volume i get stuck and get a call kernel trace. My kernel is 4.14.13 (archlinux). Unable to umount, tried to killed command, no way... what should i do ? Thanks. # btrfs fi df /mnt/vol3 Data, single: total=25.97GiB, used=6.84GiB System, DUP: