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

Re: reading an empty directory after reboot is very slow

Henrique de Moraes Holschuh wrote:
> Bob Proulx wrote:
> >   tune2fs -O dir_index /dev/sda5
> > But existing directories are not converted.  Only new directories are
> Do a forced e2fsck run on the filesystem, and it should add the
> indexes to all directories that lack it.  It can also change the
> hash algorithm.
> BTW, the e2fsck manpage states that it WILL compress directories if
> it has any reason to touch the directory.
> If you want e2fsck to rehash or compress all directories, you have
> to run it as e2fsck -D so that it will optimize/rehash every
> directory, not just those that were lacking indexes or that had to
> be repaired.

Oh!  I was unaware of the e2fsck -D option.  Good deal!

> > it though so for the most part that is okay.  It is only directories
> > such as /tmp that sporadically might have surged large that really
> > benefit from a manual recreation conversion in order to have B-trees
> > turned on for a migration to dir_index.
> If you have the resources required (RAM), always have ephemeral
> "tmp" directories in tmpfs.  All contents will be discarded on
> reboot/poweroff or if you umount the tmpfs, but it should be the
> fastest possible filesystem in Linux as long as you don't start
> swapping (xfs and ext4 are much better optimized to the "hit the
> spinning rust" case than tmpfs+swapper IME).

I also like tmpfs for /tmp for simple systems.  But it isn't a general
purpose solution for everyone.  There are many cases such as when /tmp
is used as a large file dropbox that it doesn't work to use a limited
size tmpfs.

It will take a while for people to change their habits to accomodate
the system.  In this case it means dropboxing large files in a
different directory other than /tmp.  And I don't like to work for the
machine.  I like the machine to work for me.  So I can't recommend
tmpfs /tmp for *everyone* but it does work well for the cases where it
doesn't hurt existing user practices.


Attachment: signature.asc
Description: Digital signature

Reply to: