exFAT Driver With Linux 6.13 Reduces FAT Chain Traversal For Better Performance
([Linux Storage] 4 Hours Ago
exFAT)
- Reference: 0001508710
- News link: https://www.phoronix.com/news/Linux-6.13-exFAT
- Source link:
For those making use of the Microsoft [1]exFAT file-system on Linux systems, the upcoming Linux 6.13 kernel brings an optimization that will help some operations by reducing the FAT chain traversal.
For the most part the exFAT updates In Linux 6.13 aren't too interesting. Per the Wednesday night [2]pull request :
- Handle it as the empty directory if the start cluster of stream entry is invalid.
- Valid size of steam entry cannot be greater than data size.
If valid_size is invalid, Deal with data_size.
- Move Direct-IO alignment check to before extending the valid size.
- Fix uninit-value issue reported by syzbot.
- Optimize to find directory entry-set in write_inode, rename, unlink.
The last one is interesting to optimize the find directory entry-set for writing inode, rename, and unlink operations.
That work ultimately comes down to a set of patches by Yuezhang Mo to reduce the FAT chain traversal. Yuezhang Mo explained in that patch series:
"Before this commit, ->dir and ->entry of exfat_inode_info record the first cluster of the parent directory and the directory entry index starting from this cluster.
The directory entry set will be gotten during write-back-inode/rmdir/ unlink/rename. If the clusters of the parent directory are not continuous, the FAT chain will be traversed from the first cluster of the parent directory to find the cluster where ->entry is located.
After this commit, ->dir records the cluster where the first directory entry in the directory entry set is located, and ->entry records the directory entry index in the cluster, so that there is almost no need to access the FAT when getting the directory entry set."
It should be a worthwhile optimization but no numbers were provided with the patches to quantify the performance impact of avoiding the FAT chain traversal when renaming or deleting files/folders.
In any event the exFAT support for Linux continues moving along.
[1] https://www.phoronix.com/search/exFAT
[2] https://lore.kernel.org/lkml/CAKYAXd9nv9eEHgt55sWBWo98bkOXctDJGjQo+FSJYtVGwtKOhA@mail.gmail.com/
For the most part the exFAT updates In Linux 6.13 aren't too interesting. Per the Wednesday night [2]pull request :
- Handle it as the empty directory if the start cluster of stream entry is invalid.
- Valid size of steam entry cannot be greater than data size.
If valid_size is invalid, Deal with data_size.
- Move Direct-IO alignment check to before extending the valid size.
- Fix uninit-value issue reported by syzbot.
- Optimize to find directory entry-set in write_inode, rename, unlink.
The last one is interesting to optimize the find directory entry-set for writing inode, rename, and unlink operations.
That work ultimately comes down to a set of patches by Yuezhang Mo to reduce the FAT chain traversal. Yuezhang Mo explained in that patch series:
"Before this commit, ->dir and ->entry of exfat_inode_info record the first cluster of the parent directory and the directory entry index starting from this cluster.
The directory entry set will be gotten during write-back-inode/rmdir/ unlink/rename. If the clusters of the parent directory are not continuous, the FAT chain will be traversed from the first cluster of the parent directory to find the cluster where ->entry is located.
After this commit, ->dir records the cluster where the first directory entry in the directory entry set is located, and ->entry records the directory entry index in the cluster, so that there is almost no need to access the FAT when getting the directory entry set."
It should be a worthwhile optimization but no numbers were provided with the patches to quantify the performance impact of avoiding the FAT chain traversal when renaming or deleting files/folders.
In any event the exFAT support for Linux continues moving along.
[1] https://www.phoronix.com/search/exFAT
[2] https://lore.kernel.org/lkml/CAKYAXd9nv9eEHgt55sWBWo98bkOXctDJGjQo+FSJYtVGwtKOhA@mail.gmail.com/
gnarlin