Re: [PATCH] btrfs-progs: mkfs: allow not to trim a device
On Mon, Mar 19, 2012 at 06:24:17PM +0100, Martin Steigerwald wrote: Just curious: Whats the use case for this? http://digitalvampire.org/blog/index.php/2012/03/16/you-can-never-be-too-rich-or-too-thin/ :) -- 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-progs: mkfs: allow not to trim a device
David == David Sterba dste...@suse.cz writes: Just curious: Whats the use case for this? David http://digitalvampire.org/blog/index.php/2012/03/16/you-can-never-be-too-rich-or-too-thin/ Well, a cap of 1MB per UNMAP command is absolute crazy talk. We currently do 2GB per command on ATA and 2TB per command on most SCSI targets. I don't disagree that it may make sense to have a disable discard option to mkfs. But Roland really needs to get his VPD reporting fixed. I suspect what the array meant to communicate was a 1MB discard granularity, not a 1MB per command limit...a common mistake. -- Martin K. Petersen Oracle Linux Engineering -- 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: 'bad tree block start' mount failure...
2012/3/20 Daniel J Blueman dan...@quora.org: mkfs.btrfs -m raid0 -d raid0 /dev/sdb1 /dev/sdc1 mount /dev/sdb1 /mnt umount /mnt mount /dev/sdb1 /mnt -o compress umount /mnt mount /dev/sdb1 /mnt -o ssd umount /mnt mount /dev/sdb1 /mnt -o discard umount /mnt mount /dev/sdb1 /mnt mount failure Well, I can't reproduce this. It's also true that I use some out-of-the-tree patches. I wrote this each step. They must be in a script? Ciao, Gelma -- 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: [RFC PATCH 0/5] apply rwlock for extent state
Any comments? On 03/15/2012 05:12 PM, Liu Bo wrote: This patchset is against one of project ideas, RBtree lock contention: Btrfs uses a number of rbtrees to index in-memory data structures. Some of these are dominated by reads, and the lock contention from searching them is showing up in profiles. We need to look into an RCU and sequence counter combination to allow lockless reads. The goal is to use RCU, but we take it as a long term one, and instead we use rwlock until we find a mature rcu structure for lockless read. So what we need to do is to make the code RCU friendly, and the idea mainly comes from Chris Mason: Quoted: I think the extent_state code can be much more RCU friendly if we separate the operations on the tree from operations on the individual state. In general, we can gain a lot of performance if we are able to reduce the write locks taken at endio time. Especially for reads, these are critical. If we read a 10M file with pagecache, $ dd if=/mnt/btrfs/foobar of=/dev/null bs=1M without this patchset, lock for read : lock for write ~= 2:1 with this patchset, lock for read : lock for write ~= 200:1 I've run through xfstests, and no bugs jump out by then. MORE TESTS ARE WELCOME! Liu Bo (5): Btrfs: use radix tree for checksum Btrfs: merge adjacent states as much as possible Btrfs: use large extent range for read and its endio Btrfs: apply rwlock for extent state Btrfs: avoid splitting state when truncating pagecache fs/btrfs/extent_io.c| 768 +-- fs/btrfs/extent_io.h|5 +- fs/btrfs/free-space-cache.c |5 + fs/btrfs/inode.c| 22 +- 4 files changed, 614 insertions(+), 186 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 -- 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
Synchronous snapshot delete
Hi Team, Could you let me know if you are working on.. Synchronous snapshot delete (or similar) few requested for this feature, just wanted to know if anyone has picked up this and is working on it. 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: bcache with SSD instead of battery powered raid cards
On 03/13/2012 04:06 AM, Kiran Patil wrote: Hi, Is anybody using bcache with SSD instead of battery powered raid cards with Btrfs ? Hard drives are cheap and big, SSDs are fast but small and expensive. Wouldn't it be nice if you could transparently get the advantages of both? With Bcache, you can have your cake and eat it too. Bcache is a patch for the Linux kernel to use SSDs to cache other block devices. It's analogous to L2Arc for ZFS, but Bcache also does writeback caching, and it's filesystem agnostic. It's designed to be switched on with a minimum of effort, and to work well without configuration on any setup. By default it won't cache sequential IO, just the random reads and writes that SSDs excel at. It's meant to be suitable for desktops, servers, high end storage arrays, and perhaps even embedded. http://bcache.evilpiepirate.org/ Did you ever experiment with this? What results did you find? There is also something similar called flashcache developed by some facebook engineer that I'm interested in trying. They are supposedly using this to speed up mysql+innodb. It is out of mainline tree code though, and I don't think there is much of an effort to get it in. It supports writeback, writethrough and writearound (blocks are never cached on write, only on read) caching. It uses dm-mapper to combine your 'cache block' with your 'slow spinning block' and then you put your filesystem on top of that dm device. https://github.com/facebook/flashcache Regards, --Justin -- 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 RESEND] Xfstest: make 218 support btrfs
Btrfs progs has a defragment tool, so we can test 218 on btrfs now. Signed-off-by: Liu Bo liubo2...@cn.fujitsu.com --- 218 |2 +- common.defrag |3 +++ 2 files changed, 4 insertions(+), 1 deletions(-) diff --git a/218 b/218 index 53d0b61..77782c6 100755 --- a/218 +++ b/218 @@ -44,7 +44,7 @@ _cleanup() . ./common.defrag # real QA test starts here -_supported_fs xfs ext4 +_supported_fs xfs ext4 btrfs _supported_os Linux _setup_testdir diff --git a/common.defrag b/common.defrag index 4850803..ea6c14c 100644 --- a/common.defrag +++ b/common.defrag @@ -29,6 +29,9 @@ _require_defrag() ext4|ext4dev) DEFRAG_PROG=/usr/bin/e4defrag ;; +btrfs) + DEFRAG_PROG=$BTRFS_UTIL_PROG filesystem defragment + ;; *) _notrun defragmentation not supported for fstype \$FSTYP\ ;; -- 1.6.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
