On Tue, Nov 19, 2013 at 2:59 PM, Matthias G. Eckermann <mge@suse.com> wrote:
So, at least one conclusion can be drawn from this:
Under heaving writing, btrfs induces noticeably higher read await times than ext4, resulting in the considerably sluggish system I reported initially. [...] Yes, ext4 took longer (14 minutes longer). That could be noise, the system wasn't totally idle (I was browsing with firefox, painfully slowly, but inducing some extra load). It does look though to be an I/O scheduling issue more than a performance issue, because restore times are comparable.
Well, so, in the end, btrfs was faster, but the system less responsible to user interaction. Is that the right summary?
Yep.
If yes, that would not be too bad of a result, as for a system dedicated to a database, direct user interaction is not the primary use case. :-/
Well, yes, but this effect would also be observed for other querying processes. So, the issue itself is, that the scheduler is less fair under btrfs. I know schedulers are separate from the filesystem, so I have no idea why this is the case. It shouldn't happen. But it does.
Just for my curiosity: Which type of backend did you use (HDD or SSD?) and which IO Scheduler associated?
Rotating rust (HDD), and CFQ. For a database, the recommended scheduler is deadline, but since this isn't a dedicated system (it's a development box), I kept CFQ. That actually makes the issue more strange, since CFQ is supposed to avoid this sluggishness (and it does succeed with ext4). -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org