Markus Trippelsdorf wrote:
I'm running the latest git kernel and git btrfs-progs.
When I try to run some benchmarks on my btrfs partition I always get
read errors:
(...)
FATAL: Failed to read file! file: 3 pos: 196608 errno = 22 ()
FATAL: Failed to read file! file: 13 pos: 524288 errno =
2009/6/18 Markus Trippelsdorf mar...@trippelsdorf.de:
I'm running the latest git kernel and git btrfs-progs.
When I try to run some benchmarks on my btrfs partition I always get
read errors:
phenom2 ~ # iozone -I -a -s 100M -r 4k -i 0 -i 1 -i 2
Iozone: Performance Test of File I/O
On 18. juni. 2009, at 15.56, Roy Sigurd Karlsbakk wrote:
Hi all
I have heard/read about systems from Sun and NetApp using SDs for
caching. Sun uses different SDs for read and write caching (one
being faster for reads and the other for writes). The storage
solution from Sun is based on
On Thu, Jun 18, 2009 at 03:56:23PM +0200, Roy Sigurd Karlsbakk wrote:
I have heard/read about systems from Sun and NetApp using SDs for
caching. Sun uses different SDs for read and write caching (one being
faster for reads and the other for writes). The storage solution from
Sun is based
On 18. juni. 2009, at 17.55, Tomasz Torcz wrote:
On Thu, Jun 18, 2009 at 03:56:23PM +0200, Roy Sigurd Karlsbakk wrote:
I have heard/read about systems from Sun and NetApp using SDs for
caching. Sun uses different SDs for read and write caching (one being
faster for reads and the other for
Currently btrfs has a problem where it can use a ridiculous amount of RAM simply
tracking free space. As free space gets fragmented, we end up with thousands of
entries on an rb-tree per block group, which usually spans 1 gig of area. Since
we currently don't ever flush free space cache back to
This patch moves the caching of the block group off to a kthread in order to
allow people to allocate sooner. Instead of blocking up behind the caching
mutex, we instead kick of the caching kthread, and then attempt to make an
allocation. If we cannot, we wait on the block groups caching
