Are we going to see this be part of posix_fallocate in glibc any time soon? The patch would be fairly trivial and then let application programmers use a standard interface that has a nice fallback in
I'd be dumbstruck if so. It really needs a proper fs-independent system call. This keeps coming up, and an interface has even been discussed on LKML in the past - just needs some guy to go do it. Som
maybe I'll get around to that this weekend :) I've got some ideas for some good API features that we could use (being people who are rather picky about performance and predictability in certain areas
i did kernel patches and an attempt at the glibc part of it for i386 and amd64, it needs a cleanup and reposting though. right now there is only support for xfs and ext[23], im not sure if other fs's
Hi there, we are storing realtime streaming data (multiple/random writes) in our Linux system with XFS filesystem and suffering from heavy fragementation 2GB files) before using the file system. we a
2GB files) before using the file system. we are creating the 'quick' sparse file like the following: (is this cause the problem?) /bin/dd if=/dev/zero of=/mnt/file.ivf bs=1M seek=2000000 count=1 We a
Hello again, Thanks for the info, here are more specifics on what we are trying to do: we have 200GB of harddive and would like to create 90-95 of 'video' file, each with 2GBs (data will be writting
Ying-Hung Chen wrote: See the xfsctl man page from xfsprogs, specifically XFS_IOC_RESVSP creating a sparse file will not help with fragmentation, unfortunately. Hello again, Thanks for the info, here
does this mean, if I create a 2GB file via dd (not sparse file), when i 'overwrite' to the same file, it will stay there? (same physical place) I just thought of wild idea... since i am creating 90
Ying-Hung Chen wrote: pre-allocation before writing would still be your best bet. If you pre-allocate on a fresh fs before writing, you should get very large extents. does this mean, if I create a 2G
Ying-Hung Chen wrote: pre-allocation before writing would still be your best bet. If you pre-allocate on a fresh fs before writing, you should get very large extents. does this mean, if I create a 2G
actually, performance is the problem got my attention, and when i run xfs_db and check the fragmentation, its well over 95% on one 200GB partition...... -Ying
okay, I'll give it a try tomorrow, just want to make sure, int xfsctl (const char *path, int fd, int cmd, void *ptr); path is actually the filename right? and fd is the FILE* where I open the filena
Ying-Hung Chen wrote: I guess while you played your video file, which was 2GB. Your video images were not smoothly shown on the player. It gave you an impression that there was a problem on the files
when I run the sample code, and created "testfile" [yhchen@fc3 ~]$ ./xfs_fcntl testfile [yhchen@fc3 ~]$ ls -l testfile -rwx-- 1 yhchen yhchen 0 Sep 23 14:17 testfile [yhchen@fc3 ~]$ du testfile 2048
Ying-Hung Chen wrote: when I run the sample code, and created "testfile" [yhchen@fc3 ~]$ ./xfs_fcntl testfile [yhchen@fc3 ~]$ ls -l testfile -rwx-- 1 yhchen yhchen 0 Sep 23 14:17 testfile [yhchen@fc3