Re: reading an empty directory after reboot is very slow
On Monday 13 April 2015 16:08:44 Henrique de Moraes Holschuh wrote:
> 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.
I was semi-assuming that was the case for Linux, since its a decade newer
than the Microware OS9 I was referrencing.
Thank you for the clarification.
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
Reply to: