Re: btrfs convert running out of space
Am Fri, 23 Jan 2015 04:34:19 + (UTC) schrieb Duncan <1i5t5.dun...@cox.net>: > Gareth Pye posted on Fri, 23 Jan 2015 08:58:08 +1100 as excerpted: > > > What are the chances that splitting all the large files up into sub gig > > pieces, finish convert, then recombine them all will work? > [...] > Option 2: Since new files should be created using the desired target mode > (raid1 IIRC), you may actually be able to move them off and immediately > back on, so they appear as new files and thus get created in the desired > mode. Of course the success here depends on how many you have to move > vs. the amount of free space available that will be used when you do so, > but with enough space, it should "just work". > > Note that with this method, if the files are small enough to entirely fit > one-at-a-time or a-few-at-a-time in memory (I have 16 gig RAM, for > instance, and don't tend to use more than a gig or two for apps, so could > in theory do 12-14 gig at a time for this), you can even use a tmpfs as > the temporary storage before moving them back to the target filesystem. > That should be pretty fast since the one side is all memory. With current coreutils, wouldn't that also work if he moves the files to another (temporary) subvolume? (And with future coreutils, by copying the files without using reflinks and then removing the originals.) [...] -- Marc Joliet -- "People who think they know everything really annoy those of us who know we don't" - Bjarne Stroustrup pgpGGQS6VMEBQ.pgp Description: Digitale Signatur von OpenPGP
Recovery Operation With Multiple Devices
Hi All, Just wondering how 'btrfs recovery' operates, when the source device given is one of many in an MD array - I can't find anything documentation beyond a single device use case. Does it automatically include all devices in the relevant MD array as occurs when mounting, or does it only restore the data which happened to be written to the specific, single device given ? >From an inverse perspective, how can I restore all data including snapshots, >which are spread across a damaged MD FS to a new (MD) FS ? Can send / receive do this perhaps ? Thanks in advance ! -- 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://vger.kernel.org/majordomo-info.html
[PATCH v4] btrfs: add regression test for remount with thread_pool resized
Regression test for a btrfs issue of resizing 'thread_pool' when
remount the fs.
This regression was introduced by the following linux kernel commit:
btrfs: Added btrfs_workqueue_struct implemented ordered
execution based on kernel workqueue
08a9ff3264181986d1d692a4e6fce3669700c9f8
And it was fixed by the following linux kernel commit:
btrfs: fix crash in remount(thread_pool=) case
800ee2247f483b6d05ed47ef3bbc90b56451746c
Signed-off-by: Xing Gu
---
v3->v4: Remove the check for a bug message.
v2->v3: Add the regresssion commit in description.
Remove "dmesg -c > /dev/null".
Echo "Silence is golden" to indicate that an empty output
file is expected.
v1->v2: Add the fix commit in description.
Add the check for a bug message.
---
tests/btrfs/082 | 65 +
tests/btrfs/082.out | 2 ++
tests/btrfs/group | 1 +
3 files changed, 68 insertions(+)
create mode 100755 tests/btrfs/082
create mode 100644 tests/btrfs/082.out
diff --git a/tests/btrfs/082 b/tests/btrfs/082
new file mode 100755
index 000..7a6e4b5
--- /dev/null
+++ b/tests/btrfs/082
@@ -0,0 +1,65 @@
+#!/bin/bash
+# FS QA Test No. btrfs/082
+#
+# Regression test for a btrfs issue of resizing 'thread_pool' when
+# remount the fs.
+#
+# This regression was introduced by the following linux kernel commit:
+# btrfs: Added btrfs_workqueue_struct implemented ordered
+# execution based on kernel workqueue
+# 08a9ff3264181986d1d692a4e6fce3669700c9f8
+# And it was fixed by the following linux kernel commit:
+# btrfs: fix crash in remount(thread_pool=) case
+# 800ee2247f483b6d05ed47ef3bbc90b56451746c
+#
+#---
+# Copyright (c) 2015 Fujitsu. All Rights Reserved.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation.
+#
+# This program is distributed in the hope that it would be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write the Free Software Foundation,
+# Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+#
+#---
+#
+
+seq=`basename $0`
+seqres=$RESULT_DIR/$seq
+echo "QA output created by $seq"
+
+here=`pwd`
+tmp=/tmp/$$
+status=1 # failure is the default!
+
+_cleanup()
+{
+rm -f $tmp.*
+}
+
+trap "_cleanup ; exit \$status" 0 1 2 3 15
+
+# get standard environment, filters and checks
+. ./common/rc
+. ./common/filter
+
+# real QA test starts here
+_supported_fs btrfs
+_supported_os Linux
+_require_scratch
+
+_scratch_mkfs > /dev/null
+
+_scratch_mount "-o thread_pool=6"
+_scratch_mount "-o remount,thread_pool=10"
+
+echo "Silence is golden"
+status=0
+exit
diff --git a/tests/btrfs/082.out b/tests/btrfs/082.out
new file mode 100644
index 000..2977f14
--- /dev/null
+++ b/tests/btrfs/082.out
@@ -0,0 +1,2 @@
+QA output created by 082
+Silence is golden
diff --git a/tests/btrfs/group b/tests/btrfs/group
index e2b..fd2fa76 100644
--- a/tests/btrfs/group
+++ b/tests/btrfs/group
@@ -84,3 +84,4 @@
079 auto rw metadata
080 auto snapshot
081 auto quick clone
+082 auto quick remount
--
1.9.3
--
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://vger.kernel.org/majordomo-info.html
Re: btrfs convert running out of space
Gareth Pye posted on Fri, 23 Jan 2015 08:58:08 +1100 as excerpted: > What are the chances that splitting all the large files up into sub gig > pieces, finish convert, then recombine them all will work? [Further context removed due to the hassle of trying to sort the top-posting into proper order to reply in /proper/ context.] A likely easier alternative would be to temporarily move those files off the filesystem in question. Option 1: Do that (thumb drives work well for this if you're not talking /terabytes/ and don't have a spare hard drive handy), finish the convert, and move them back. Option 2: Since new files should be created using the desired target mode (raid1 IIRC), you may actually be able to move them off and immediately back on, so they appear as new files and thus get created in the desired mode. Of course the success here depends on how many you have to move vs. the amount of free space available that will be used when you do so, but with enough space, it should "just work". Note that with this method, if the files are small enough to entirely fit one-at-a-time or a-few-at-a-time in memory (I have 16 gig RAM, for instance, and don't tend to use more than a gig or two for apps, so could in theory do 12-14 gig at a time for this), you can even use a tmpfs as the temporary storage before moving them back to the target filesystem. That should be pretty fast since the one side is all memory. This is actually the solution recommended when a btrfs from ext* conversion didn't have the recommended defrag and balance done afterward, or when even after a defrag, the balance fails due to overly large ext* extents, compared to the normally 1-gig extents that btrfs usually works with. Move all the gig-plus files off the filesystem, thus eliminating the old overly large extents, and back, so the files get created with native btrfs sized extents. The solution is known to work for that, so assuming a similar issue here, it should work here as well. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- 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://vger.kernel.org/majordomo-info.html
Re: [PULL] [PATCH 0/3] Btrfs, fixes for freezing vs pending changes
Hi David, Would you please delay this patchset to be merged into next rc? In fact, I think there is a better solution for such problem. 1) mount option change problem. In fact, there is no need to start a transaction to change mount option, since it doesn't change anything on-disk. What we need is just to keep the mount option doesn't change during transaction. (Although several exceptions still exists, but should be OK) So I prefer to add a rwsem to protect mount_opt, each btrfs_transaction will hold the read lock on it and upon btrfs_put_transaction(), read unlock it. btrfs_parse_option() should wait for write lock to change it. BTW, current btrfs_parse_options() is not atomic, and for nospace_cache mount option, SPACE_CACHE bit is always first set and later cleared, which created a window btrfs_commit_transaction() can create space cache. I'll solve it by using copy-n-update method. 2) Sysfs label/feature change problem For this problem, I agree with Miao to keep the behavior the same as "btrfs pro set" command, since it will write something on disk. And since btrfs_ioctl_set_fslabel() is synchronized, I didn't see the necessity to change it to async using sysfs. What do you think about this idea? Although, I'm afraid this may revert all your pending_changes patches :-< (In fact, I'm already dealing the mount option change problem) Thanks, Qu Original Message Subject: [PULL] [PATCH 0/3] Btrfs, fixes for freezing vs pending changes From: David Sterba To: Date: 2015年01月21日 02:05 There was some churn regarding the patches to $SUBJ, here's what I think is enough to fix it for 3.19. It's based on top of my other patch "btrfs: sync ioctl, handle errors after transaction start" that might land in Chris' for-linus already so it's not included here. The patches are for review by the involved people, also available in this branch: git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux.git David Sterba (1): btrfs: remove a no-op unfreeze superbock callback Qu Wenruo (2): btrfs: Fix the bug that fs_info->pending_changes is never cleared. btrfs: Don't call btrfs_start_transaction() on frozen fs to avoid deadlock. fs/btrfs/super.c | 16 ++-- fs/btrfs/transaction.c | 2 +- 2 files changed, 11 insertions(+), 7 deletions(-) -- 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://vger.kernel.org/majordomo-info.html
Re: [PATCH] btrfs: fix raid56 scrub failed in xfstests btrfs/072
Original Message Subject: Re: [PATCH] btrfs: fix raid56 scrub failed in xfstests btrfs/072 From: David Sterba To: Date: 2015年01月16日 19:00 On Fri, Jan 09, 2015 at 09:39:40AM +0800, Gui Hecheng wrote: The xfstests btrfs/072 reports uncorrectable read errors in dmesg, because scrub forgets to use commit_root for parity scrub routine and scrub attempts to scrub those extents items whose contents are not fully on disk. To fix it, we just add the @search_commit_root flag back. Signed-off-by: Gui Hecheng Signed-off-by: Qu Wenruo Chris, please add this patch to 3.19-rc queue, followup to the new raid56 scrub code. Hi Chris, This patch doesn't seems to be included in 3.19-rc5, would you please add it to next rc? Thanks, Qu -- 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://vger.kernel.org/majordomo-info.html
[PATCH] btrfs-progs:qgroup:make large size aligned
problem: when the size is too big, the output format will be unaligned.
the __update__columns_max_len function has been updated to fix this
problem
Signed-off-by: Fan Chengniang
---
In my patch "[PATCH v3] make btrfs qgroups show human readable sizes"
I forget to update the function __update__columns_max_len which may
cause large size unaligned.
qgroup.c | 13 +
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/qgroup.c b/qgroup.c
index 8ec55df..3e4a6ed 100644
--- a/qgroup.c
+++ b/qgroup.c
@@ -915,6 +915,7 @@ static void __update_columns_max_len(struct btrfs_qgroup
*bq,
struct btrfs_qgroup_list *list = NULL;
char tmp[100];
int len;
+ unsigned unit_mode = btrfs_qgroup_columns[column].unit_mode;
switch (column) {
@@ -926,26 +927,22 @@ static void __update_columns_max_len(struct btrfs_qgroup
*bq,
btrfs_qgroup_columns[column].max_len = len;
break;
case BTRFS_QGROUP_RFER:
- sprintf(tmp, "%llu", bq->rfer);
- len = strlen(tmp);
+ len = strlen(pretty_size_mode(bq->rfer, unit_mode));
if (btrfs_qgroup_columns[column].max_len < len)
btrfs_qgroup_columns[column].max_len = len;
break;
case BTRFS_QGROUP_EXCL:
- sprintf(tmp, "%llu", bq->excl);
- len = strlen(tmp);
+ len = strlen(pretty_size_mode(bq->excl, unit_mode));
if (btrfs_qgroup_columns[column].max_len < len)
btrfs_qgroup_columns[column].max_len = len;
break;
case BTRFS_QGROUP_MAX_RFER:
- sprintf(tmp, "%llu", bq->max_rfer);
- len = strlen(tmp);
+ len = strlen(pretty_size_mode(bq->max_rfer, unit_mode));
if (btrfs_qgroup_columns[column].max_len < len)
btrfs_qgroup_columns[column].max_len = len;
break;
case BTRFS_QGROUP_MAX_EXCL:
- sprintf(tmp, "%llu", bq->max_excl);
- len = strlen(tmp);
+ len = strlen(pretty_size_mode(bq->max_excl, unit_mode));
if (btrfs_qgroup_columns[column].max_len < len)
btrfs_qgroup_columns[column].max_len = len;
break;
--
1.9.1
--
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://vger.kernel.org/majordomo-info.html
Re: [PATCH v4] btrfs-progs: make btrfs qgroups show human readable sizes
在 2015年01月23日 00:24, David Sterba 写道: On Thu, Jan 22, 2015 at 04:11:43PM +0800, Fan Chengniang wrote: v3: - remove --human-readable option - add --raw, --si, --iec, --kbytes, --mbytes, --gbytes, --tbytes options - by default, sizes are shown in human readable format - make columns which show sizes align to right. Others aligned to left. v4: - change default output be raw, instead of human readable.Because xfstest result depend on the raw output. I've merged v3, that's what we want to present to the user. I'll send a patch to fstests to force the raw bytes output. there is a bug in v3 which will cause the output format unaligned. I found it and fix it in v4. I will send it to you. -- 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://vger.kernel.org/majordomo-info.html
Re: [PATCH] Btrfs: fix setup_leaf_for_split() to avoid leaf corruption
On Tue, Jan 20, 2015 at 12:40:53PM +, Filipe Manana wrote:
> We were incorrectly detecting when the target key didn't exist anymore
> after releasing the path and re-searching the tree. This could make
> us split or duplicate (btrfs_split_item() and btrfs_duplicate_item()
> are its only callers at the moment) an item when we should not.
>
> For the case of duplicating an item, we currently only duplicate
> checksum items (csum tree) and file extent items (fs/subvol trees).
> For the checksum items we end up overriding the item completely,
> but for file extent items we update only some of their fields in
> the copy (done in __btrfs_drop_extents), which means we can end up
> having a logical corruption for some values.
>
> Also for the case where we duplicate a file extent item it will make
> us produce a leaf with a wrong key order, as btrfs_duplicate_item()
> advances us to the next slot and then its caller sets a smaller key
> on the new item at that slot (like in __btrfs_drop_extents() e.g.).
> Alternatively if the tree search in setup_leaf_for_split() leaves
> with path->slots[0] == btrfs_header_nritems(path->nodes[0]), we end
> up accessing beyond the leaf's end (when we check if the item's size
> has changed) and make our caller insert an item at the invalid slot
> btrfs_header_nritems(path->nodes[0]) + 1, causing an invalid memory
> access if the leaf is full or nearly full.
Good catch, it's just the similar case as what commit 0b43e04f
("Btrfs: fix leaf corruption after __btrfs_drop_extents") fixes.
Reviewed-by: Liu Bo
Thanks,
-liubo
>
> This issue has been present since the introduction of this function
> in 2009:
>
> Btrfs: Add btrfs_duplicate_item
> commit ad48fd754676bfae4139be1a897b1ea58f9aaf21
>
> Signed-off-by: Filipe Manana
> ---
> fs/btrfs/ctree.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/fs/btrfs/ctree.c b/fs/btrfs/ctree.c
> index 14a72ed..78e8993c1 100644
> --- a/fs/btrfs/ctree.c
> +++ b/fs/btrfs/ctree.c
> @@ -4356,13 +4356,15 @@ static noinline int setup_leaf_for_split(struct
> btrfs_trans_handle *trans,
> path->search_for_split = 1;
> ret = btrfs_search_slot(trans, root, &key, path, 0, 1);
> path->search_for_split = 0;
> + if (ret > 0)
> + ret = -EAGAIN;
> if (ret < 0)
> goto err;
>
> ret = -EAGAIN;
> leaf = path->nodes[0];
> - /* if our item isn't there or got smaller, return now */
> - if (ret > 0 || item_size != btrfs_item_size_nr(leaf, path->slots[0]))
> + /* if our item isn't there, return now */
> + if (item_size != btrfs_item_size_nr(leaf, path->slots[0]))
> goto err;
>
> /* the leaf has changed, it now has room. return now */
> --
> 2.1.3
>
> --
> 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://vger.kernel.org/majordomo-info.html
--
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://vger.kernel.org/majordomo-info.html
Re: btrfs convert running out of space
PS: the only snapshots are of apt-mirror, which doesn't have large files. On Fri, Jan 23, 2015 at 8:58 AM, Gareth Pye wrote: > What are the chances that splitting all the large files up into sub > gig pieces, finish convert, then recombine them all will work? > > On Wed, Jan 21, 2015 at 3:03 PM, Chris Murphy wrote: >> On Tue, Jan 20, 2015 at 4:04 PM, Gareth Pye wrote: >>> Yeah, we don't have that much space spare :( >>> >>> File system has been going strong from when it was created with early >>> RAID5 code, then converted to RAID10 with kernel 3.12. >>> >>> There aren't any nocow files to my knowledge but there are plenty of >>> files larger than a gig on the file system. The first few results from >>> logical-resolve have been for files in the 1G~2G range, so that could >>> be some sticky spaghetti. >> >> Are any of those big files in a snapshot? The snapshotting may be >> pinning a bunch of large extents, so even if it seems like the volume >> has enough space, it might actually be running out of space. All I can >> think of is progressively removing the files that are implicated in >> the conversion failure. That could mean just deleting older snapshots >> that you probably don't need, progressively getting to the point where >> you migrate those files off this fs to another one, and then delete >> them (all instances in all subvol/snapshots) and just keep trying. >> >> Is a btrfs check happy? Or does it complain about anything? >> >> I've had quite good luck just adding a drive (two drives for raid1/10 >> volumes) to an existing btrfs volume, they don't have to be drdb, they >> can be local block devices, either physical drives or LV's. I've even >> done this with flash drives (kinda scary and slow but it worked). >> >> I'd still suggest contingency planning in case this volume becomes >> temperamental and you have no choice but to migrate it elsewhere. >> Better to do it on your timetable than the filesystem's. >> >> -- >> Chris Murphy > > > > -- > Gareth Pye > Level 2 MTG Judge, Melbourne, Australia > "Dear God, I would like to file a bug report" -- Gareth Pye Level 2 MTG Judge, Melbourne, Australia "Dear God, I would like to file a bug report" -- 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://vger.kernel.org/majordomo-info.html
Re: btrfs convert running out of space
What are the chances that splitting all the large files up into sub gig pieces, finish convert, then recombine them all will work? On Wed, Jan 21, 2015 at 3:03 PM, Chris Murphy wrote: > On Tue, Jan 20, 2015 at 4:04 PM, Gareth Pye wrote: >> Yeah, we don't have that much space spare :( >> >> File system has been going strong from when it was created with early >> RAID5 code, then converted to RAID10 with kernel 3.12. >> >> There aren't any nocow files to my knowledge but there are plenty of >> files larger than a gig on the file system. The first few results from >> logical-resolve have been for files in the 1G~2G range, so that could >> be some sticky spaghetti. > > Are any of those big files in a snapshot? The snapshotting may be > pinning a bunch of large extents, so even if it seems like the volume > has enough space, it might actually be running out of space. All I can > think of is progressively removing the files that are implicated in > the conversion failure. That could mean just deleting older snapshots > that you probably don't need, progressively getting to the point where > you migrate those files off this fs to another one, and then delete > them (all instances in all subvol/snapshots) and just keep trying. > > Is a btrfs check happy? Or does it complain about anything? > > I've had quite good luck just adding a drive (two drives for raid1/10 > volumes) to an existing btrfs volume, they don't have to be drdb, they > can be local block devices, either physical drives or LV's. I've even > done this with flash drives (kinda scary and slow but it worked). > > I'd still suggest contingency planning in case this volume becomes > temperamental and you have no choice but to migrate it elsewhere. > Better to do it on your timetable than the filesystem's. > > -- > Chris Murphy -- Gareth Pye Level 2 MTG Judge, Melbourne, Australia "Dear God, I would like to file a bug report" -- 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://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] Btrfs: Add code to support file creation time
> @@ -5729,6 +5744,7 @@ static struct inode *btrfs_new_inode(struct > btrfs_trans_handle *trans, > struct btrfs_path *path; > struct btrfs_inode_ref *ref; > struct btrfs_key key[2]; > + struct timespec current_time; > u32 sizes[2]; > int nitems = name ? 2 : 1; > unsigned long ptr; > @@ -5824,7 +5840,13 @@ static struct inode *btrfs_new_inode(struct > btrfs_trans_handle *trans, > > inode_init_owner(inode, dir, mode); > inode_set_bytes(inode, 0); > - inode->i_mtime = inode->i_atime = inode->i_ctime = CURRENT_TIME; > + > + current_time = CURRENT_TIME; > + inode->i_mtime = current_time; > + inode->i_atime = current_time; > + inode->i_ctime = current_time; > + BTRFS_I(inode)->i_otime = current_time; I might have just set mtime to CURRENT_TIME then the rest to mtime. It'd be a touch less noisy. Author's choice, though :). Any plans to add it to send/recv? 766702ef (Alexander Block 2012-07-28 14:11:31 +0200 2480) /* TODO Add otime support when the otime patches get into upstream */ - z -- 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://vger.kernel.org/majordomo-info.html
[PATCH v2] Btrfs: Add code to support file creation time
From: chandan r
This patch adds a new member to the 'struct btrfs_inode' structure to hold
the file creation time.
Signed-off-by: chandan
[refreshed, removed btrfs_inode_otime]
Signed-off-by: David Sterba
---
This is based on top of https://patchwork.kernel.org/patch/5484061/ that cleans
up [cma]time use, otime is treated the same way.
fs/btrfs/btrfs_inode.h | 3 +++
fs/btrfs/delayed-inode.c | 10 ++
fs/btrfs/inode.c | 29 +++--
3 files changed, 40 insertions(+), 2 deletions(-)
diff --git a/fs/btrfs/btrfs_inode.h b/fs/btrfs/btrfs_inode.h
index 4aadadcfab20..de5e4f2adfea 100644
--- a/fs/btrfs/btrfs_inode.h
+++ b/fs/btrfs/btrfs_inode.h
@@ -185,6 +185,9 @@ struct btrfs_inode {
struct btrfs_delayed_node *delayed_node;
+ /* File creation time. */
+ struct timespec i_otime;
+
struct inode vfs_inode;
};
diff --git a/fs/btrfs/delayed-inode.c b/fs/btrfs/delayed-inode.c
index 116eb4bed8d3..82f0c7c95474 100644
--- a/fs/btrfs/delayed-inode.c
+++ b/fs/btrfs/delayed-inode.c
@@ -1769,6 +1769,11 @@ static void fill_stack_inode_item(struct
btrfs_trans_handle *trans,
inode->i_ctime.tv_sec);
btrfs_set_stack_timespec_nsec(&inode_item->ctime,
inode->i_ctime.tv_nsec);
+
+ btrfs_set_stack_timespec_sec(&inode_item->otime,
+BTRFS_I(inode)->i_otime.tv_sec);
+ btrfs_set_stack_timespec_nsec(&inode_item->otime,
+BTRFS_I(inode)->i_otime.tv_nsec);
}
int btrfs_fill_inode(struct inode *inode, u32 *rdev)
@@ -1810,6 +1815,11 @@ int btrfs_fill_inode(struct inode *inode, u32 *rdev)
inode->i_ctime.tv_sec = btrfs_stack_timespec_sec(&inode_item->ctime);
inode->i_ctime.tv_nsec = btrfs_stack_timespec_nsec(&inode_item->ctime);
+ BTRFS_I(inode)->i_otime.tv_sec =
+ btrfs_stack_timespec_sec(&inode_item->otime);
+ BTRFS_I(inode)->i_otime.tv_nsec =
+ btrfs_stack_timespec_nsec(&inode_item->otime);
+
inode->i_generation = BTRFS_I(inode)->generation;
BTRFS_I(inode)->index_cnt = (u64)-1;
diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index 87f1d9b8727e..5db15b21280a 100644
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -3535,6 +3535,11 @@ static void btrfs_read_locked_inode(struct inode *inode)
inode->i_ctime.tv_sec = btrfs_timespec_sec(leaf, &inode_item->ctime);
inode->i_ctime.tv_nsec = btrfs_timespec_nsec(leaf, &inode_item->ctime);
+ BTRFS_I(inode)->i_otime.tv_sec =
+ btrfs_timespec_sec(leaf, &inode_item->otime);
+ BTRFS_I(inode)->i_otime.tv_nsec =
+ btrfs_timespec_nsec(leaf, &inode_item->otime);
+
inode_set_bytes(inode, btrfs_inode_nbytes(leaf, inode_item));
BTRFS_I(inode)->generation = btrfs_inode_generation(leaf, inode_item);
BTRFS_I(inode)->last_trans = btrfs_inode_transid(leaf, inode_item);
@@ -3669,6 +3674,11 @@ static void fill_inode_item(struct btrfs_trans_handle
*trans,
btrfs_set_token_timespec_nsec(leaf, &item->ctime,
inode->i_ctime.tv_nsec, &token);
+ btrfs_set_token_timespec_sec(leaf, btrfs_inode_otime(item),
+BTRFS_I(inode)->i_otime.tv_sec, &token);
+ btrfs_set_token_timespec_nsec(leaf, btrfs_inode_otime(item),
+ BTRFS_I(inode)->i_otime.tv_nsec, &token);
+
btrfs_set_token_inode_nbytes(leaf, item, inode_get_bytes(inode),
&token);
btrfs_set_token_inode_generation(leaf, item, BTRFS_I(inode)->generation,
@@ -5244,6 +5254,7 @@ static struct inode *new_simple_dir(struct super_block *s,
struct btrfs_root *root)
{
struct inode *inode = new_inode(s);
+ struct timespec current_time;
if (!inode)
return ERR_PTR(-ENOMEM);
@@ -5256,7 +5267,11 @@ static struct inode *new_simple_dir(struct super_block
*s,
inode->i_op = &btrfs_dir_ro_inode_operations;
inode->i_fop = &simple_dir_operations;
inode->i_mode = S_IFDIR | S_IRUGO | S_IWUSR | S_IXUGO;
- inode->i_mtime = inode->i_atime = inode->i_ctime = CURRENT_TIME;
+ current_time = CURRENT_TIME;
+ inode->i_mtime = current_time;
+ inode->i_atime = current_time;
+ inode->i_ctime = current_time;
+ BTRFS_I(inode)->i_otime = current_time;
return inode;
}
@@ -5729,6 +5744,7 @@ static struct inode *btrfs_new_inode(struct
btrfs_trans_handle *trans,
struct btrfs_path *path;
struct btrfs_inode_ref *ref;
struct btrfs_key key[2];
+ struct timespec current_time;
u32 sizes[2];
int nitems = name ? 2 : 1;
unsigned long ptr;
@@ -5824,7 +5840,13 @@ static struct inode *btrfs_new_inode(struct
btrfs_trans_handle *trans,
inode_in
Re: [PATCH v4] btrfs-progs: make btrfs qgroups show human readable sizes
On Thu, Jan 22, 2015 at 04:11:43PM +0800, Fan Chengniang wrote: > v3: > - remove --human-readable option > - add --raw, --si, --iec, --kbytes, --mbytes, --gbytes, --tbytes options > - by default, sizes are shown in human readable format > - make columns which show sizes align to right. Others aligned to left. > v4: > - change default output be raw, instead of human readable.Because xfstest > result depend on the raw output. I've merged v3, that's what we want to present to the user. I'll send a patch to fstests to force the raw bytes output. -- 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://vger.kernel.org/majordomo-info.html
Re: replace seed/sprout hangs (regression ?)
On Thu, Jan 22, 2015 at 10:03 AM, Anand Jain wrote: > > The following test case hangs as of now, but as I remember Fujitsu > had sent a patch to fix this, a long time back. Can't find now, > any idea. ? > > Test case: >add a spout device >replace seed / sprout device > > hangs at: > (btrfs_reada_wait+0x4d/0xb0) No idea when it happened. But perhaps, it's a good time to start having an xfstest for it? :) thanks > > Thanks, Anand > -- > 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://vger.kernel.org/majordomo-info.html -- Filipe David Manana, "Reasonable men adapt themselves to the world. Unreasonable men adapt the world to themselves. That's why all progress depends on unreasonable men." -- 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://vger.kernel.org/majordomo-info.html
replace seed/sprout hangs (regression ?)
The following test case hangs as of now, but as I remember Fujitsu had sent a patch to fix this, a long time back. Can't find now, any idea. ? Test case: add a spout device replace seed / sprout device hangs at: (btrfs_reada_wait+0x4d/0xb0) Thanks, Anand -- 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://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] btrfs: qgroup: destroy related qgroup when removing subvolume if needed.
On 01/22/2015 02:16 PM, Wang Shilong wrote:
> Hello,
>
>> When removing a subvol, if the related qgroup has no child qgroup, we should
>> destroy
>> it at the same time. Also remove the TODO entry in qgroup.c.
> My two cents here:
>
> Take a quick look at this, i am not sure whether this is right way to do it.
>
> Actually, i think we can only remove a subvolume qgroup safely when both
> refer and excl are 0,
> because for subvolume removal case, to make qgroup accounting right, we need
> walk tree.
>
> At this time, qgroup walking might have not finished, if we remove this
> qgroup directly,
> accounting for this qgroup will be skipped.
Good point!
>
> Maybe we could remove such qgroup when at qgroup accounting, we find an
> qgroup’s refer and excl
> are 0, we could remove it, or we do it at the background..
>
> Also, there is another risk, that is to say, if qgroup accounting not work
> right, So
> we might need gurantee that subvolume it going to be deleted or have been
> deleted at the same time,
> then we could remove qgroup safely etc.
Yes, you are right. This is not a good timing to remove the qgroup directly.
I need some more investigation for a better solution.
As I have some emergency to deal with in this period, maybe the V2 will
come a little late.
Sorry about it.
Thanx
Yang
>
>
>> Signed-off-by: Dongsheng Yang
>> ---
>> fs/btrfs/inode.c | 4
>> fs/btrfs/qgroup.c | 1 -
>> 2 files changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
>> index e687bb0..31de211 100644
>> --- a/fs/btrfs/inode.c
>> +++ b/fs/btrfs/inode.c
>> @@ -59,6 +59,7 @@
>> #include "backref.h"
>> #include "hash.h"
>> #include "props.h"
>> +#include "qgroup.h"
>>
>> struct btrfs_iget_args {
>> struct btrfs_key *location;
>> @@ -4029,6 +4030,9 @@ int btrfs_unlink_subvol(struct btrfs_trans_handle
>> *trans,
>> ret = btrfs_update_inode_fallback(trans, root, dir);
>> if (ret)
>> btrfs_abort_transaction(trans, root, ret);
>> +ret = btrfs_remove_qgroup(trans, root->fs_info, objectid);
>> +if (ret == -EBUSY)
>> +ret = 0;
>> out:
>> btrfs_free_path(path);
>> return ret;
>> diff --git a/fs/btrfs/qgroup.c b/fs/btrfs/qgroup.c
>> index c3b1e4f..303c078 100644
>> --- a/fs/btrfs/qgroup.c
>> +++ b/fs/btrfs/qgroup.c
>> @@ -35,7 +35,6 @@
>> #include "qgroup.h"
>>
>> /* TODO XXX FIXME
>> - * - subvol delete -> delete when ref goes to 0? delete limits also?
>> * - reorganize keys
>> * - compressed
>> * - sync
>> --
>> 1.8.4.2
>>
>> --
>> 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://vger.kernel.org/majordomo-info.html
> Best Regards,
> Wang Shilong
>
> .
>
--
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://vger.kernel.org/majordomo-info.html
[PATCH v4] btrfs-progs: make btrfs qgroups show human readable sizes
add --raw, --si, --iec, --kbytes, --mbytes, --gbytes, --tbytes options
make columns which show sizes align to right. Others aligned to left.
example:
qgroupid rfer excl max_rfer max_excl parent child
-- -
0/5 37.90MiB 37.90MiB 1.00GiB0.00B 1/1,1/2 ---
0/256144.00KiB 144.00KiB0.00B0.00B 1/2 ---
1/1 37.90MiB 37.90MiB0.00B0.00B --- 0/5
1/2 38.04MiB 38.04MiB0.00B0.00B --- 0/5,0/256
Signed-off-by: Fan Chengniang
---
v2:
- change -h option to --human-readable
- merge need_print and human_readable into format
- add print_group_size function
v3:
- remove --human-readable option
- add --raw, --si, --iec, --kbytes, --mbytes, --gbytes, --tbytes options
- by default, sizes are shown in human readable format
- make columns which show sizes align to right. Others aligned to left.
v4:
- change default output be raw, instead of human readable.Because xfstest
result depend on the raw output.
Documentation/btrfs-qgroup.txt | 14
cmds-qgroup.c | 59 --
qgroup.c | 82 +++---
qgroup.h | 1 +
4 files changed, 117 insertions(+), 39 deletions(-)
diff --git a/Documentation/btrfs-qgroup.txt b/Documentation/btrfs-qgroup.txt
index 3e13373..89dbd6c 100644
--- a/Documentation/btrfs-qgroup.txt
+++ b/Documentation/btrfs-qgroup.txt
@@ -73,6 +73,20 @@ print max exclusive size of qgroup.
list all qgroups which impact the given path(include ancestral qgroups)
-f
list all qgroups which impact the given path(exclude ancestral qgroups)
+--raw
+raw numbers in bytes, without the 'B' suffix.
+--iec
+select the 1024 base for the following options, according to the IEC standard.
+--si
+select the 1000 base for the following options, according to the SI standard.
+--kbytes
+show sizes in KiB, or kB with --si.
+--mbytes
+show sizes in MiB, or MB with --si.
+--gbytes
+show sizes in GiB, or GB with --si.
+--tbytes
+show sizes in TiB, or TB with --si.
--sort=[\+/-][,[+/-]]...
list qgroups in order of .
+
diff --git a/cmds-qgroup.c b/cmds-qgroup.c
index 957fbc9..2883ca2 100644
--- a/cmds-qgroup.c
+++ b/cmds-qgroup.c
@@ -208,19 +208,26 @@ static const char * const cmd_qgroup_show_usage[] = {
"btrfs qgroup show -pcreFf "
"[--sort=qgroupid,rfer,excl,max_rfer,max_excl] ",
"Show subvolume quota groups.",
- "-p print parent qgroup id",
- "-c print child qgroup id",
- "-r print max referenced size of qgroup",
- "-e print max exclusive size of qgroup",
- "-F list all qgroups which impact the given path"
+ "-p print parent qgroup id",
+ "-c print child qgroup id",
+ "-r print max referenced size of qgroup",
+ "-e print max exclusive size of qgroup",
+ "-F list all qgroups which impact the given path"
"(include ancestral qgroups)",
- "-f list all qgroups which impact the given path"
+ "-f list all qgroups which impact the given path"
"(exclude ancestral qgroups)",
+ "--raw raw numbers in bytes",
+ "--iec use 1024 as a base (KiB, MiB, GiB, TiB)",
+ "--si use 1000 as a base (kB, MB, GB, TB)",
+ "--kbytes show sizes in KiB, or kB with --si",
+ "--mbytes show sizes in MiB, or MB with --si",
+ "--gbytes show sizes in GiB, or GB with --si",
+ "--tbytes show sizes in TiB, or TB with --si",
"--sort=qgroupid,rfer,excl,max_rfer,max_excl",
- " list qgroups in order of qgroupid,"
+ " list qgroups in order of qgroupid,"
"rfer,max_rfer or max_excl",
- " you can use '+' or '-' in front of each item.",
- " (+:ascending, -:descending, ascending default)",
+ " you can use '+' or '-' in front of each item.",
+ " (+:ascending, -:descending, ascending default)",
NULL
};
@@ -234,6 +241,8 @@ static int cmd_qgroup_show(int argc, char **argv)
int c;
u64 qgroupid;
int filter_flag = 0;
+ int option_index = 0;
+ unsigned unit_mode = UNITS_RAW;
struct btrfs_qgroup_comparer_set *comparer_set;
struct btrfs_qgroup_filter_set *filter_set;
@@ -241,16 +250,41 @@ static int cmd_qgroup_show(int argc, char **argv)
comparer_set = btrfs_qgroup_alloc_comparer_set();
struct option long_options[] = {
{"sort", 1, NULL, 'S'},
+ {"raw", no_argument, NULL, 0},
+ {"kbytes", no_argument, NULL, 0},
+ {"mbytes", no_argument, NULL, 0},
+ {"gbytes", no_argument, NULL, 0},
+
