linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* device ordered files (for backups etc)
@ 2001-05-15  4:10 Jon Peatfield
  0 siblings, 0 replies; only message in thread
From: Jon Peatfield @ 2001-05-15  4:10 UTC (permalink / raw)
  To: linux-kernel; +Cc: J.S.Peatfield

While reading the "getting fs access events" thread I remembered
something which I've been meaning to look at for ages.

[some history]
I don't trust programs which dump file systems by reading the data
directly from the block device (I'm never sure that they get things
right).  I prefer to do backups through the standard fs interfaces (so
logically we do 2 steps, make a list of files and then archive them).

However, this does mean that the order of real block reads may not be
very good (since files may accessed in an order which doesn't minimise
seeks).  Ignoring the problem of files with blocks spread far apart,
it seems clear that mapping the file to a rough index into the device
and ordering the reading of the files by this index ought to reduce
the seeks.

Now most systems provide no interface for this (pity), though Linux
does through the FIBMAP ioctl() (for fs which support bmap at least).
However to use this we need to open() all the files get the block
index, sort them and then reopen the files in the right order.

There is also the problem that we are (indirectly) reading the
directories to do the readdir()/lstat() etc in some arbitrary order,
so causing more seeks.

Is there some trick I'm missing or is there really no way to avoid
these seek penalty and go through the standard fs interfaces?

 -- Jon

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2001-05-15  4:11 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-05-15  4:10 device ordered files (for backups etc) Jon Peatfield

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).