[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Things to do this week instead of arguing about mixers



-------- Original Message --------
Subject: Re: Things to do this week instead of arguing about mixers
From: Eric Sandeen <sandeen redhat com>
To: Development discussions related to Fedora <fedora-devel-list redhat com>
Date: 04/27/2009 03:53 PM


Try downloading a large (multi-gigabyte) torrent on ext4 or xfs or
btrfs; see what the resulting file layout looks like if your client does
not preallocate.  Now use a client that preallocates the space and try
again.  Calling fallocate() first for the full file size will help on
all these filesystems (well, TBH, I have not tested it on btrfs).

If there are well-defined interfaces to give hints to the filesystem
about the ultimate state of a file, it's a nice feature, not a bug.

Sure, filesystems should do the best they can in the absence of hints,
but performing well (or better) _with_ a hint is not indicative of a bug.


I can truely only speak for XFS, but btrfs might be similar:

XFS waits[1] to allocate space for a few seconds in order to see the full file size of the write() you want to commit. This allows for a more complete allocation at the cost of data integrity.

deluge, one bittorrent client, gives you the option of full or dynamic allocation. I download multi-gigabyte torrents often with deluge and full allocation.

In the end -- SSDs should be cheaper so this discussion is moot.

[1] http://en.wikipedia.org/wiki/Xfs#Delayed_allocation


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]