On Tue, 25 Mar 2014 09:41:42 AM Marc MERLIN wrote:
4 hours to stat 700K files. That's bad...
Even 11mn to restat them just to count them looks bad too.
One way to get an idea of where that's happening is to run the command with
strace -c to build up a table of times spent in each system call,
On Sat, Apr 12, 2014 at 12:15:14AM +1000, Chris Samuel wrote:
On Tue, 25 Mar 2014 09:41:42 AM Marc MERLIN wrote:
4 hours to stat 700K files. That's bad...
Even 11mn to restat them just to count them looks bad too.
One way to get an idea of where that's happening is to run the command
Marc MERLIN posted on Fri, 11 Apr 2014 10:23:46 -0700 as excerpted:
Is anyone else using btrfs on top of dmcrypt and software raid 5?
There may be others, but I haven't seen them active on-list. For active
list users, I think you're leading the pack in that area. =:^/
--
Duncan - List
On Fri, 11 Apr 2014 10:23:46 -0700
Marc MERLIN m...@merlins.org wrote:
Is anyone else using btrfs on top of dmcrypt and software raid 5?
I use Btrfs accessed via NBD over a LAN, physically stored on mdadm RAID5, a
setup which is similar to yours in that the block device used for Btrfs has a
So, since then I found out in the thread
Subject: Re: btrfs on 3.14rc5 stuck on btrfs_tree_read_lock sync
that my btrfs filesystem has a clear problem, which Josef and Chris are
still looking into.
Basically, I've had btrfs near deadlocks on this filesystem:
INFO: task
Le 25 mars 2014 à 12:13, Martin a écrit:
On 25/03/14 01:49, Marc MERLIN wrote:
It took 18H to rm it in 3 tries:
And is not *the 512kByte raid chunk* going to give you horrendous write
amplification?! For example, rm updates a few bytes in one 4kByte
metadata block and the system has to then
On Tue, Mar 25, 2014 at 12:13:50PM +, Martin wrote:
On 25/03/14 01:49, Marc MERLIN wrote:
I had a tree with some amount of thousand files (less than 1 million)
on top of md raid5.
It took 18H to rm it in 3 tries:
I ran another test after typing the original Email:
