[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: