On Wednesday, April 29, 2015 5:20:08 PM PDT, Dave Chinner wrote:
It's easy to be fast on empty filesystems. XFS does not aim to be
fast in such situations - it aims to have consistent performance
across the life of the filesystem.
In this case, ext4, btrfs and tux3 have optimal allocation
On Wednesday, April 29, 2015 8:50:57 PM PDT, Mike Galbraith wrote:
On Wed, 2015-04-29 at 13:40 -0700, Daniel Phillips wrote:
That order of magnitude latency difference is striking. It sounds
good, but what does it mean? I see a smaller difference here, maybe
because of running under KVM.
On Wednesday, April 29, 2015 6:46:16 PM PDT, Dave Chinner wrote:
I measured fsync performance using a 7200 RPM disk as a virtual
drive under KVM, configured with cache=none so that asynchronous
writes are cached and synchronous writes translate into direct
writes to the block device.
Yup, a
On Thursday, April 30, 2015 2:17:55 PM PDT, James Cloos wrote:
DP == Daniel Phillips dan...@phunq.net writes:
DP you build userspace tools from the hirofumi-user branch
In a fresh clone there is no hirofumi-user branch, only hirofumi and master:
:; cat .git/packed-refs
# pack-refs with:
On Thu, Apr 30, 2015 at 11:00:05AM +0200, Martin Steigerwald wrote:
IOWS, XFS just hates your disk. Spend $50 and buy a cheap SSD and
the problem goes away. :)
I am quite surprised that a traditional filesystem that was created in the
age of rotating media does not like this kind of media
Daniel Phillips wrote:
On 04/30/2015 07:28 AM, Howard Chu wrote:
You're reading into it what isn't there. Spreading over the disk isn't (just)
about avoiding
fragmentation - it's about delivering consistent and predictable latency. It is
undeniable that if
you start by only allocating from
