Richard W.M. Jones wrote:
On Wed, Sep 03, 2008 at 11:19:04AM -0500, Eric Sandeen wrote:
I'd appreciate any and all testing, benchmarking & feedback that people would be willing to do. Just getting more exposure in real-life scenarios would be great.
As with any filesystem, I wouldn't put your only copy of your most precious data on it - use good sense about backups etc - but ext4 has made good progress since F9 on both stability and performance, so have at it!
Persistent pre-allocation[1] is something that virt-manager could really use when it has to allocate multi-gigabyte images. A few questions about this feature though:
(a) Is it exposed as a syscall anywhere? I don't see it in the header files of my Rawhide system (2.6.27).
Hm, I probably need to get the fallocate.h header file included if it's not so that sys_fallocate can be used directly, but it is also exposed via posix_fallocate in glibc - tested here on xfs just because xfs_bmap is a handy way to show that it actually works via glibc:
[root@inode fallocate]# ./test_posix_fallocate testfile 0 16384 [root@inode fallocate]# xfs_bmap -vv testfile testfile: EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL FLAGS 0: [0..31]: 138928..138959 0 (138928..138959) 32 10000 FLAG Values: 010000 Unwritten preallocated extent 001000 Doesn't begin on stripe unit 000100 Doesn't end on stripe unit 000010 Doesn't begin on stripe width 000001 Doesn't end on stripe width
the ->fallocate op is hooked up for ext4, xfs, and ocfs2 at this time.
(b) Will preallocate "do the right thing" on filesystems that don't directly support it?
calling sys_fallocate() will give you -EOPNOTSUPP; using posix_fallocate() falls back to writing zeros IIRC.
(c) Does ext4 preallocate in the background? A synchronous preallocate call isn't much use to virt-manager.
It does not, but what is the concern? It doesn't take much time:
(on ext4 this time):
[root@inode test]# time test_posix_fallocate testfile 0 10737418240
real 0m0.009s user 0m0.000s sys 0m0.009s [root@inode test]# ls -lh testfile -rw-r--r-- 1 root root 10G 2008-09-03 12:30 testfile [root@inode test]# du -hc testfile 11G testfile 11G total
-Eric
Rich.
[1] http://en.wikipedia.org/wiki/Ext4#Persistent_pre-allocation
#define _LARGEFILE64_SOURCE #define _GNU_SOURCE
#include <fcntl.h> #include <unistd.h> #include <stdio.h> #include <stdlib.h> #include <errno.h> #include <string.h> #include <sys/types.h>
int main(int argc, char **argv) { int fd; int ret; loff_t offset; loff_t len; char *fname;
fname = argv[1]; offset = atoll(argv[2]); len = atoll(argv[3]);
printf("file %s offset %llu (%s) length %llu (%s)\n", fname, offset, argv[2], len, argv[3]); fd = open(fname, O_CREAT|O_RDWR, 0666); if (fd < 0) { perror("Error opening file"); return 1; }
ret = posix_fallocate64(fd, offset, len); if (ret < 0) perror("Error allocating space");
close(fd); return 0; }
Eric Sandeen wrote:
Richard W.M. Jones wrote:
On Wed, Sep 03, 2008 at 11:19:04AM -0500, Eric Sandeen wrote:
I'd appreciate any and all testing, benchmarking & feedback that people would be willing to do. Just getting more exposure in real-life scenarios would be great.
As with any filesystem, I wouldn't put your only copy of your most precious data on it - use good sense about backups etc - but ext4 has made good progress since F9 on both stability and performance, so have at it!
Persistent pre-allocation[1] is something that virt-manager could really use when it has to allocate multi-gigabyte images. A few questions about this feature though:
(a) Is it exposed as a syscall anywhere? I don't see it in the header files of my Rawhide system (2.6.27).
Hm, I probably need to get the fallocate.h header file included if it's not so that sys_fallocate can be used directly,
Ah, it should be there:
[root@inode ~]# rpm -ql kernel-headers | grep falloc /usr/include/linux/falloc.h
-Eric