Re: [PATCH 2/2] xfstests: meet btrfs fs size requirement in _scratch_mkfs_sized()
On Fri, Nov 4, 2011 at 1:39 PM, Christoph Hellwig h...@infradead.org wrote: On Fri, Nov 04, 2011 at 10:38:04AM +0800, Eryu Guan wrote: btrfs requires at least 256M file system size, so check 'fssize' in _scratch_mkfs_sized first and give it a proper value. Otherwise mkfs.btrfs will complain something like File system size 267386880 bytes is too small, 256M is required at least This makes 015 077 and 083 run on btrfs. But it's not really going to test the ENOSPC conditions it was designed to exercise. It would be better to either find a way to make btrfs run on smaller filesystem, or call _notrun for too small filesystems on btrfs from _scratch_mkfs_sized. Yes, you're right. I checked 015 (it would dd zero to btrfs to full) but forgot to check 077 and 083. I'll try to find a better way. Thanks for reviewing! Eryu Guan Signed-off-by: Eryu Guan guane...@gmail.com --- common.rc | 5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/common.rc b/common.rc index e948169..ab61786 100644 --- a/common.rc +++ b/common.rc @@ -356,6 +356,11 @@ _scratch_mkfs_sized() /sbin/mkfs.$FSTYP $MKFS_OPTIONS -b $blocksize $SCRATCH_DEV $blocks ;; btrfs) + # btrfs needs at least 256M file system size + if [ $fssize -lt $((256*1024*1024)) ] + then + fssize=$((256*1024*1024)) + fi $MKFS_BTRFS_PROG $MKFS_OPTIONS -b $fssize $SCRATCH_DEV ;; *) -- 1.7.7.1 ___ xfs mailing list x...@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ---end quoted text--- -- 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 2/2] xfstests: meet btrfs fs size requirement in _scratch_mkfs_sized()
On 11/4/2011 7:06 AM, Eryu Guan wrote: On Fri, Nov 4, 2011 at 1:39 PM, Christoph Hellwig h...@infradead.org wrote: On Fri, Nov 04, 2011 at 10:38:04AM +0800, Eryu Guan wrote: btrfs requires at least 256M file system size, so check 'fssize' in _scratch_mkfs_sized first and give it a proper value. Otherwise mkfs.btrfs will complain something like File system size 267386880 bytes is too small, 256M is required at least Commit bd7d6d45 from Zhong, Xin xin.zh...@intel.com with date 6/21/2011 removed the 256MB size limitation in mkfs.c in btrfs-progs. This makes 015 077 and 083 run on btrfs. But it's not really going to test the ENOSPC conditions it was designed to exercise. It would be better to either find a way to make btrfs run on smaller filesystem, or call _notrun for too small filesystems on btrfs from _scratch_mkfs_sized. Yes, you're right. I checked 015 (it would dd zero to btrfs to full) but forgot to check 077 and 083. I'll try to find a better way. Thanks for reviewing! Eryu Guan Signed-off-by: Eryu Guan guane...@gmail.com --- common.rc |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/common.rc b/common.rc index e948169..ab61786 100644 --- a/common.rc +++ b/common.rc @@ -356,6 +356,11 @@ _scratch_mkfs_sized() /sbin/mkfs.$FSTYP $MKFS_OPTIONS -b $blocksize $SCRATCH_DEV $blocks ;; btrfs) +# btrfs needs at least 256M file system size + if [ $fssize -lt $((256*1024*1024)) ] + then + fssize=$((256*1024*1024)) + fi $MKFS_BTRFS_PROG $MKFS_OPTIONS -b $fssize $SCRATCH_DEV ;; *) -- 1.7.7.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: understanding the tree-log
On 11/4/2011 1:09 AM, Liu Bo wrote: Btrfs has an expensive commit transaction, if we commit a transaction every time we fsync, the performance is not that good. Instead of this, we introduce a write-ahead log to make our fsync faster. So if you do fsync for your data, it means your data is safely in the log tree, then if a crash takes place, the data can be recovered from log. How can you write to the log tree without a full commit? The tree of tree roots has to point to the root node of the log tree, so when you write out the log tree, that needs updated too, which requires a full commit doesn't it? -- 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: fix delayed insertion reservations
We all keep getting those stupid warnings from use_block_rsv when running
stress.sh, and it's because the delayed insertion stuff is being stupid. It's
not the delayed insertion stuffs fault, it's all just stupid. When marking an
inode dirty for oh say updating the time on it, we just do a
btrfs_join_transaction, which doesn't reserve any space. This is stupid because
we're going to have to have space reserve to make this change, but we do it
because it's fast because chances are we're going to call it over and over again
and it doesn't matter. Well thanks to the delayed insertion stuff this is
mostly the case, so we do actually need to make this reservation. So if
trans-bytes_reserved is 0 then try to do a normal reservation. If not return
ENOSPC which will make the btrfs_dirty_inode start a proper transaction which
will let it do the whole ENOSPC dance and reserve enough space for the delayed
insertion to steal the reservation from the transaction.
The other stupid thing we do is not reserve space for the inode when writing to
the thing. Usually this is ok since we have to update the time so we'd have
already done all this work before we get to the endio stuff, so it doesn't
matter. But this is stupid because we could write the data after the
transaction commits where we changed the mtime of the inode so we have to cow
all the way down to the inode anyway. This used to be masked by the delalloc
reservation stuff, but because we delay the update it doesn't get masked in this
case. So again the delayed insertion stuff bites us in the ass. So if our
trans-block_rsv is delalloc, just steal the reservation from the delalloc
reserve. Hopefully this won't bite us in the ass, but I've said that before.
With this patch stress.sh no longer spits out those stupid warnings (famous last
words). Thanks,
Signed-off-by: Josef Bacik jo...@redhat.com
---
fs/btrfs/delayed-inode.c | 36
1 files changed, 28 insertions(+), 8 deletions(-)
diff --git a/fs/btrfs/delayed-inode.c b/fs/btrfs/delayed-inode.c
index fc4026a..ef6efe7 100644
--- a/fs/btrfs/delayed-inode.c
+++ b/fs/btrfs/delayed-inode.c
@@ -624,13 +624,36 @@ static int btrfs_delayed_inode_reserve_metadata(
u64 num_bytes;
int ret;
- if (!trans-bytes_reserved)
- return 0;
-
src_rsv = trans-block_rsv;
dst_rsv = root-fs_info-delayed_block_rsv;
num_bytes = btrfs_calc_trans_metadata_size(root, 1);
+
+ /*
+* btrfs_dirty_inode will update the inode under btrfs_join_transaction
+* which doesn't reserve space for speed. This is a problem since we
+* still need to reserve space for this update, so try to reserve the
+* space.
+*
+* Now if src_rsv == delalloc_block_rsv we'll let it just steal since
+* we're accounted for.
+*/
+ if (!trans-bytes_reserved
+ src_rsv != root-fs_info-delalloc_block_rsv) {
+ ret = btrfs_block_rsv_add(root, dst_rsv, num_bytes);
+ /*
+* Since we're under a transaction reserve_metadata_bytes could
+* try to commit the transaction which will make it return
+* EAGAIN to make us stop the transaction we have, so return
+* ENOSPC instead so that btrfs_dirty_inode knows what to do.
+*/
+ if (ret == -EAGAIN)
+ ret = -ENOSPC;
+ if (!ret)
+ node-bytes_reserved = num_bytes;
+ return ret;
+ }
+
ret = btrfs_block_rsv_migrate(src_rsv, dst_rsv, num_bytes);
if (!ret)
node-bytes_reserved = num_bytes;
@@ -1686,11 +1709,8 @@ int btrfs_delayed_update_inode(struct btrfs_trans_handle
*trans,
}
ret = btrfs_delayed_inode_reserve_metadata(trans, root, delayed_node);
- /*
-* we must reserve enough space when we start a new transaction,
-* so reserving metadata failure is impossible
-*/
- BUG_ON(ret);
+ if (ret)
+ goto release_node;
fill_stack_inode_item(trans, delayed_node-inode_item, inode);
delayed_node-inode_dirty = 1;
--
1.7.5.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
btrfsck status?
Hello! I read Chris was supposed to demonstrate btrfsck on LinuxCon[0]. Does anybody knows if that ever happen? Also, does btrfsck development moved to the new GIT repository, or is it still not released? I'm holding to my broken btrfs partition[0] for more than a year now :-/ Thanks. [1] http://article.gmane.org/gmane.comp.file-systems.btrfs/9423 -- Yo'av Moshe -- 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 delayed insertion reservations V2
On Fri, Nov 04, 2011 at 05:18:54PM -0400, Josef Bacik wrote: V1-V2: I stupidly thought I could get away with some flushing if we needed space but I was wrong, we could deadlock, so add a btrfs_add_bytes_noflush variant that will not do any flushing and will just return ENOSPC which will let us fallback and do our full flushing. fs/btrfs/ctree.h |3 +++ fs/btrfs/delayed-inode.c | 36 fs/btrfs/extent-tree.c | 18 ++ 3 files changed, 49 insertions(+), 8 deletions(-) This helps but it I've got a bunch of these in the log now: btrfs_dirty_inode: 205 callbacks suppressed btrfs: fail to dirty inode 1294 error -28 btrfs: fail to dirty inode 1208 error -28 btrfs: fail to dirty inode 714 error -28 btrfs: fail to dirty inode 1772 error -28 btrfs: fail to dirty inode 1389 error -28 btrfs: fail to dirty inode 770 error -28 btrfs: fail to dirty inode 345 error -28 btrfs: fail to dirty inode 1533 error -28 btrfs: fail to dirty inode 624 error -28 btrfs: fail to dirty inode 1085 error -28 -chris -- 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
