ext4 testing in the F10 release cycle

Eric Sandeen sandeen at redhat.com
Wed Sep 3 17:36:55 UTC 2008


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 at inode fallocate]# ./test_posix_fallocate testfile 0 16384
[root at 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 at inode test]# time test_posix_fallocate testfile 0 10737418240

real    0m0.009s
user    0m0.000s
sys     0m0.009s
[root at inode test]# ls -lh testfile
-rw-r--r-- 1 root root 10G 2008-09-03 12:30 testfile
[root at 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;
}




More information about the fedora-test-list mailing list