Sven Witterstein posted on Sun, 15 Mar 2015 02:30:11 +0100 as excerpted:
Probably an option-parameter in analogy to (single-spindle pre-ssd ideas
for the I/O scheduler) like
elevator=cfq (for btrfs=try to balance reads [...]
elevator=noop (assign by even/odd, current behavior (testing)
Hi Duncan,
thank you for that explanation
The existing algorithm is a very simple even/odd PID-based algorithm.
Thus, single-thread testing will indeed always read from the same side of
the pair-mirror (since btrfs raid1 and raid10 are pair-mirrored, no N-way-
mirroring available yet, tho it's
Hello,
I have used btrfs and zfs for some years and feel pretty confident about
their administration - and both with ther snaps and subvols saved me
quite often.
I had to grow my 4x250GB Raid10-Backup-Array to a 6x500GB raid10-backup
array - the slower half of 4 1TB 2.5 Spinpoint M8's. were
Sven Witterstein posted on Tue, 10 Mar 2015 00:45:23 +0100 as excerpted:
During balance or copies, the second image of the stripeset A + B | A' +
B' is never used, thus throwing away about 40% of performance, e.g. it
NEVER used A' + B' to read from even if 50% of the needed assembled data
Hi Everyone,
I wrote:
I have a particularly uncomplicated setup (a desktop PC with a hard
disk) and I'm seeing particularly slow performance from btrfs. A `git
status` in the linux source tree takes about 46 seconds after dropping
caches, whereas on other machines using ext4 this takes about
On Mon, 22 Sep 2014 13:59:03 +0200, David Sterba wrote:
On Fri, Sep 19, 2014 at 01:34:38PM +, Holger Hoffstätte wrote:
I'd also love a technical explanation why this happens and how it could
be fixed. Maybe it's just a consequence of how the metadata tree(s)
are laid out on disk.
The
On Mon, Sep 22, 2014 at 12:37:59PM +, Holger Hoffstätte wrote:
Thanks Dave - that confirms everything I (unscientifically ;) observed so
far, since I also tried to use find to warm up (in the hope it would
cache the relevant metadata blocks), but running with strace showed that
it does -
Am Freitag, 19. September 2014, 13:51:22 schrieb Holger Hoffstätte:
On Fri, 19 Sep 2014 13:18:34 +0100, Rob Spanton wrote:
I have a particularly uncomplicated setup (a desktop PC with a hard
disk) and I'm seeing particularly slow performance from btrfs. A `git
status` in the linux
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 20/09/14 09:23, Marc Dietrich wrote:
Am Freitag, 19. September 2014, 13:51:22 schrieb Holger
Hoffstätte:
On Fri, 19 Sep 2014 13:18:34 +0100, Rob Spanton wrote:
I have a particularly uncomplicated setup (a desktop PC with a
hard disk) and
Hi,
Am Samstag 20 September 2014, 22:04:16 schrieb Wang Shilong:
Hi,
just my two cents here.^_^
Am Freitag, 19. September 2014, 13:51:22 schrieb Holger Hoffstätte:
On Fri, 19 Sep 2014 13:18:34 +0100, Rob Spanton wrote:
I have a particularly uncomplicated setup (a desktop PC with a
Hi,
I have a particularly uncomplicated setup (a desktop PC with a hard
disk) and I'm seeing particularly slow performance from btrfs. A `git
status` in the linux source tree takes about 46 seconds after dropping
caches, whereas on other machines using ext4 this takes about 13s. My
mail client
Le vendredi 19 septembre 2014, 13:18:34 Rob Spanton a écrit :
I have a particularly uncomplicated setup (a desktop PC with a hard
disk) and I'm seeing particularly slow performance from btrfs.
Weeelll I have the same over-complicated kind of setup, and an Arch Linux
BTRFS system which used to
are
one of the known pathological cases for COW filesystems in general; the
solution is to mark the files as NOCOW (see the info about VM images in
[1] and [2], the same suggestions apply to database files).
As for git, I haven't seen any performance issues specific to BTRFS; are
you using any
had any performance issues with BTRFS
since about 3.10, even on the systems my employer is using Fedora 20 on,
and those use only a Core 2 Duo Processor, DDR2-800 RAM, and SATA2 hard
drives.
HTH
smime.p7s
Description: S/MIME Cryptographic Signature
storage, and sqlite database files are
one of the known pathological cases for COW filesystems in general; the
solution is to mark the files as NOCOW (see the info about VM images in
[1] and [2], the same suggestions apply to database files).
As for git, I haven't seen any performance issues
On Fri, 19 Sep 2014 13:18:34 +0100, Rob Spanton wrote:
I have a particularly uncomplicated setup (a desktop PC with a hard
disk) and I'm seeing particularly slow performance from btrfs. A `git
status` in the linux source tree takes about 46 seconds after dropping
caches, whereas on other
On Fri, 19 Sep 2014 13:18:34 +0100, Rob Spanton wrote:
I have a particularly uncomplicated setup (a desktop PC with a hard
disk) and I'm seeing particularly slow performance from btrfs. A `git
status` in the linux source tree takes about 46 seconds after dropping
caches, whereas on other
On 2014-09-19 09:51, Holger Hoffstätte wrote:
On Fri, 19 Sep 2014 13:18:34 +0100, Rob Spanton wrote:
I have a particularly uncomplicated setup (a desktop PC with a hard
disk) and I'm seeing particularly slow performance from btrfs. A `git
status` in the linux source tree takes about 46
On 09/19/2014 08:18 AM, Rob Spanton wrote:
Hi,
I have a particularly uncomplicated setup (a desktop PC with a hard
disk) and I'm seeing particularly slow performance from btrfs. A `git
status` in the linux source tree takes about 46 seconds after dropping
caches, whereas on other machines
On Fri, 19 Sep 2014 10:53:03 -0400, Austin S Hemmelgarn wrote:
I find that kind of funny, because regardless of filesystem, stat() is
one of the *slowest* syscalls on almost every *nix system in existence.
Sure. I didn't mean to imply that stat() in its various incarnations is
fast by itself,
Hi,
Thanks for the response everyone.
I wrote:
I have a particularly uncomplicated setup (a desktop PC with a hard
disk) and I'm seeing particularly slow performance from btrfs. A `git
status` in the linux source tree takes about 46 seconds after dropping
caches, whereas on other machines
On 09/19/2014 11:51 AM, Rob Spanton wrote:
Hi,
Thanks for the response everyone.
I wrote:
I have a particularly uncomplicated setup (a desktop PC with a hard
disk) and I'm seeing particularly slow performance from btrfs. A `git
status` in the linux source tree takes about 46 seconds after
On Fri, Sep 19, 2014 at 01:51:22PM +, Holger Hoffstätte wrote:
On Fri, 19 Sep 2014 13:18:34 +0100, Rob Spanton wrote:
I have a particularly uncomplicated setup (a desktop PC with a hard
disk) and I'm seeing particularly slow performance from btrfs. A `git
status` in the linux
Rob Spanton posted on Fri, 19 Sep 2014 17:51:09 +0100 as excerpted:
The evolution problem has been improved: the sqlite db that it was using
had over 18000 fragments, so I got evolution to recreate that file with
nocow set. It now takes only 30s to load my mail rather than 80s,
which is
I'm trying to do some incremental product builds on btrfs.
My general workflow is:
for CLN in CHANGES:
(1) sync CLN in /btrfs/current
(2) build
(3) if btrfs_with_snapshots: snap to /btrfs/CLN
I tried 3 ways:
ext3 as baseline,
btrfs w/o snapshots,
btrfs with snapshots
And, when doing
On Thu, 2009-04-02 at 09:33 -0700, Anupam Garg wrote:
I'm trying to do some incremental product builds on btrfs.
My general workflow is:
for CLN in CHANGES:
(1) sync CLN in /btrfs/current
(2) build
(3) if btrfs_with_snapshots: snap to /btrfs/CLN
I tried 3 ways:
ext3 as
26 matches
Mail list logo
