Hi all.
I was doing some testing with writing out data to a BTFS filesystem
with the compress-force option. With 1 program running, I saw
btfs-delalloc taking about 1 CPU worth of time, much as could be
expected. I then started up 2 programs at the same time, writing data
to the BTRFS volume. b
The latest unstable git pull fixed a little problem I had with rm -r.
With a filled up filesystem, rm -rwould stop after a few minutes say
"filesystem full', but a subsequent rm -r would clear the filesystem.
Now, it acts as it should, and removed all the files and directories
the first time.
--
I can tell you from experience that the later unstable git pull works
much better in this regard. I have a 299GB filesystem compressed to
1.2TB full with 507M free. And it handles the ENOSPC condition like
it should.
On Wed, Apr 7, 2010 at 10:48 AM, Josef Bacik wrote:
> On Wed, Apr 07, 2010 at
Linux kernel 2.6.33
mkfs.btrfs -d raid0 -L storage -m raid1 /dev/sdg2 /dev/sdh2 /dev/sdi2 /dev/sdj2
mount -t btrfs -o thread_pool=8,noatime /dev/sdg2 /storage
running dbench with 512 processes
Please see attached dmesg output. The system stayed up, but the disk
stopped responding.
--
Andy Carlso
I was wondering if there is a newer BTRFS version floating around
somewhere. The version tag on the one I got from git is "Btrfs
v2.6.27-rc7-59199-g3f6fae9", which seems kinda old, even though the
kernel is 2.6.32. Thanks, and sorry for the newbie question, but the
git unstable is the only place
