Re: reading an empty directory after reboot is very slow
On Mon, Apr 13, 2015, at 13:48, Gene Heskett wrote:
> I wonder if our "sort" utilities also do that file shrink?
No. It is something the VFS (generic filesystem layer inside the kernel) or filesystem itself would have to do, due to atomicity requirements.
> Unrelated of course, but of all the directory sorters I have written for
> a much smaller OS, one whose "dir" command presents you with an unsorted
> listing, we have dsort for cli use, and gsort for use when called by a
> gui button. Both of these basically do a bubble sort on the directory,
> which in this examnple case is itself a file, with the output of the
> sort being re-written as the sorted list, with all the deleted entries
> removed, and the directory file itself truncated at the end of the last
> valid entry. Otherwise, this file systems directories can grow quite
> large even if it does reuse the data slot occupied by a deleted file for
> a new file entry to conserve space.
Typical way to do this in Unix (danger: NOT atomic), is to create a new dir, move files to it in the order you want the inodes created, then fsync+fdatasync, rmdir old, mv new old. Do that using separate filesystems ofr new and old, and you will also defragment the files.
I don't think XFS's defrag utility does it, because it operates at a file/inode level an inode/file at a time. e2fsck might, though, as it does optimize inode hashing in directories. I have no idea about e4defrag.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique de Moraes Holschuh <hmh@debian.org>
Reply to: