These are next after extents, 64-bit and metadata_csum useful features for ext4.
Details
Details
- Reviewers
kevlo pfg - Commits
- rS328564: Add flex_bg/meta_bg features RW support.
Tested on different combinations of features with next script:
Diff Detail
Diff Detail
- Repository
- rS FreeBSD src repository - subversion
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
Comment Actions
Hmm.. it seems like we are getting to a rather complete ext4 implementation, which is positive. On the downside the code is diverging from UFS. We just can't have both I guess.
In any case , let me mention that EXT4F_RO_INCOMPAT_SUPP was created as a dirty hack: to workaround for features that we were not planning to support at all but that we needed to fake in order to read the partition.
We should remove EXT4F_RO_INCOMPAT_SUPP as it has fulfilled its purpose.
Have you tested performance improvements from these features? They could be the basis for a conference paper :).
| sys/fs/ext2fs/ext2fs.h | ||
|---|---|---|
| 329 ↗ | (On Diff #38142) | Can you please also update the comment in the lines above? Particularly Lines 325 and 326 are relelvant to this change. |
Comment Actions
A sidenote: I just noticed META_BG is supported on ext3 too.
https://ext4.wiki.kernel.org/index.php/Frequently_Asked_Questions
Comment Actions
There are another features like RO_COMPAT_QUOTA, INCOMPAT_INLINE_DATA, etc, but from my current point of view, it is not so, important, if it will be required to implement it. I think it a not a problem.
The only feature, which will be difficult to implement is RO_COMPAT_BIGALLOC, but I hope it will be not widely used by linux.
In any case , let me mention that EXT4F_RO_INCOMPAT_SUPP was created as a dirty hack: to workaround for features that we were not planning to support at all but that we needed to fake in order to read the partition.
We should remove EXT4F_RO_INCOMPAT_SUPP as it has fulfilled its purpose.
Yep, I will prepare the commit to remove it.
Have you tested performance improvements from these features? They could be the basis for a conference paper :).
I am not sure, that any of implemented ext4 features will provide the performance improvements, because these features a not targeted for it, so performance measurement is not actual.
Also, if you mean, comparing it with linux driver, freebsd will fail in all cases) because, it is "native" file-system for linux and freebsd driver implementation is slightly simplified comparing with it.
Comment Actions
I haven't looked at ext4 for a while but most of those features seem to require some obscure collaboration from the kernel, that is out of the scope of the driver. There's also the issue that ost of the interesting enhancements in linux assume there is journalling.
In any case , let me mention that EXT4F_RO_INCOMPAT_SUPP was created as a dirty hack: to workaround for features that we were not planning to support at all but that we needed to fake in order to read the partition.
We should remove EXT4F_RO_INCOMPAT_SUPP as it has fulfilled its purpose.Yep, I will prepare the commit to remove it.
Have you tested performance improvements from these features? They could be the basis for a conference paper :).
I am not sure, that any of implemented ext4 features will provide the performance improvements, because these features a not targeted for it, so performance measurement is not actual.
Hmm.. right. Most of the features are actually enhancements for fsck: checksumming will probably hit performance.
Also, if you mean, comparing it with linux driver, freebsd will fail in all cases) because, it is "native" file-system for linux and freebsd driver implementation is slightly simplified comparing with it.
The objectives have been different but at some point our ext2 had the same basic performance of UFS1 and linux's ext2, which was actually faster than ext3. We have never made comparisons with ext4.
Comment Actions
I am not sure, that journal feature is required for non-native file system, also it will be difficult to test it.
In any case , let me mention that EXT4F_RO_INCOMPAT_SUPP was created as a dirty hack: to workaround for features that we were not planning to support at all but that we needed to fake in order to read the partition.
We should remove EXT4F_RO_INCOMPAT_SUPP as it has fulfilled its purpose.Yep, I will prepare the commit to remove it.
Have you tested performance improvements from these features? They could be the basis for a conference paper :).
I am not sure, that any of implemented ext4 features will provide the performance improvements, because these features a not targeted for it, so performance measurement is not actual.
Hmm.. right. Most of the features are actually enhancements for fsck: checksumming will probably hit performance.
Also, if you mean, comparing it with linux driver, freebsd will fail in all cases) because, it is "native" file-system for linux and freebsd driver implementation is slightly simplified comparing with it.
The objectives have been different but at some point our ext2 had the same basic performance of UFS1 and linux's ext2, which was actually faster than ext3. We have never made comparisons with ext4.
The comparing performance of ufs and extfs is an interesting. I sure, that ufs will be faster, but how many times... May be will make some measurements little bit later.
Comment Actions
No, I didn't mean it is required, just that some features, as implemented upstream, are meant for journalling.
Delayed allocation takes into account the journal and do some of the operations in memory before hitting the disk. Some other features, like the multiblock allocator, are undocumented.
Some people have considered (and even started) implementing journalling but it is probably a waste of time. This doesn't meant ext4 couldn't be made to work as well as more "native" filesystem, but we should probably discuss this in a mailing list instead of a Differential Review ;).