I'm trying to get custom extent size per file working, but XFS_IOC_FSSETXATTR ioctl returns with EINVAL, both from my code or from xfs_io. The environment is SLES9 SP2, 2.6.5-7.252 kernel, xfsprogs-2
Indeed it has. I'm not sure which kernel version this was merged into, but the rough timeframe can be seen on http://oss.sgi.com/projects/xfs/ on the "recent changes" table. It wont be there in any S
I've checked source code of 2.6.16.13-4 in SUSE 10.1, it looks like this limitation is no longer there. However the lack of support for this in SLES9 complicates things a bit, for example we're using
OK. Are you certain you need this feature? (can you describe your usage a bit?) You can get large contiguous chunks of disk space via large direct writes for example, or preallocation, so maybe you c
The application is reading and writing sparse file of 0.5-1GB, with heavy skew toward read. The data is written in clusters of various size, depending on data stream type. The filesystem is constant
Hmm. Yes, thats the one. No, but it does the best it can under the circumstances, which is usually pretty good. But its not really "extra" if you know you're going to use it, right? Its a different c
I think that I'll go for the custom extent size as the harder guarantee against fragmentation. It also looks to me that custom extent is easier for application to implement. Are there any other reas
Not really... only things like "its not there in old kernels", and "its not seen the level of testing and exposure of other XFS features, like preallocation", etc. Oh, I see. You don't need to estima
I'm trying to get custom extent size per file working, but XFS_IOC_FSSETXATTR ioctl returns with EINVAL, both from my code or from xfs_io. The environment is SLES9 SP2, 2.6.5-7.252 kernel, xfsprogs-2
Indeed it has. I'm not sure which kernel version this was merged into, but the rough timeframe can be seen on http://oss.sgi.com/projects/xfs/ on the "recent changes" table. It wont be there in any S
I've checked source code of 2.6.16.13-4 in SUSE 10.1, it looks like this limitation is no longer there. However the lack of support for this in SLES9 complicates things a bit, for example we're using
OK. Are you certain you need this feature? (can you describe your usage a bit?) You can get large contiguous chunks of disk space via large direct writes for example, or preallocation, so maybe you c
The application is reading and writing sparse file of 0.5-1GB, with heavy skew toward read. The data is written in clusters of various size, depending on data stream type. The filesystem is constant
Hmm. Yes, thats the one. No, but it does the best it can under the circumstances, which is usually pretty good. But its not really "extra" if you know you're going to use it, right? Its a different c
I think that I'll go for the custom extent size as the harder guarantee against fragmentation. It also looks to me that custom extent is easier for application to implement. Are there any other reas
Not really... only things like "its not there in old kernels", and "its not seen the level of testing and exposure of other XFS features, like preallocation", etc. Oh, I see. You don't need to estima
I'm trying to get custom extent size per file working, but XFS_IOC_FSSETXATTR ioctl returns with EINVAL, both from my code or from xfs_io. The environment is SLES9 SP2, 2.6.5-7.252 kernel, xfsprogs-2
Indeed it has. I'm not sure which kernel version this was merged into, but the rough timeframe can be seen on http://oss.sgi.com/projects/xfs/ on the "recent changes" table. It wont be there in any S
I've checked source code of 2.6.16.13-4 in SUSE 10.1, it looks like this limitation is no longer there. However the lack of support for this in SLES9 complicates things a bit, for example we're using
OK. Are you certain you need this feature? (can you describe your usage a bit?) You can get large contiguous chunks of disk space via large direct writes for example, or preallocation, so maybe you c