Things to do this week instead of arguing about mixers
sandeen at redhat.com
Mon Apr 27 20:25:44 UTC 2009
Richard W.M. Jones wrote:
> On Mon, Apr 27, 2009 at 02:10:10PM -0500, Eric Sandeen wrote:
>> long fallocate(int fd, int mode, loff_t offset, loff_t len);
> I have some questions about this syscall: One serious problem is that
> the allocations seem to take a long time to complete (this is on ext3,
> I've not tried ext4 on my host machine yet). Is it possible to have
> the fallocate happen 'in the background'? Is the extent-based system
> used by ext4 more efficient in this respect?
fallocate() will return -ENOSYS on ext3; posix_fallocate() will succeed
but will fall back to writing 0s on ext3, which is probably what you are
seeing, and you may not want to call it for that reason...
See my original email on why ext4 is faster and how it behaves
>> * Come up with a list of apps which could benefit:
>> - all torrent clients?
>> - rsync? (some patches have floated before)
>> - rpm? (file installation and/or db files?)
>> - databases?
>> - file downloaders?
>> - virt image tools?
> In the virt space, these:
> - libvirt storage backend
Looks like libvirt already calls posix_fallocate(). How is this used or
configured? Going forward, fallocate() may be the better choice, or a
configurable one if there's any actual use case for using
posix_fallocate() instead on ext3.
> - virt-install (python)
> - libguestfs / guestfish
> - ovirt (maybe?)
> For the virt C code, it would be extremely useful to have the autoconf
> state of play sorted out first, so we can just add the right macros to
> our configure.ac scripts.
Yep, that's why I listed it as the first bullet point :)
More information about the devel