lkml.org 
[lkml]   [1999]   [Mar]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [OFFTOPIC] Re: disk head scheduling
Hi,

On Sun, 21 Mar 1999 11:49:31 -0800, jg@pa.dec.com (Jim Gettys) said:

> There was a paper at OSDI '99 I didn't pay much attention to at the time
> (never having been an I/O systems guru) that attempts to help this problem
> by various hints getting passed between the disk subsystem and the operating
> system, ...

> Was anyone else on this mailing list present and awake enough to remember
> the gist of this paper?

Yes. The paper ("Virtual Log Based File Systems for a Programmable
Disk") concentrated on doing write-allocation on the disk itself, but
near the end they did spend some time talking about the programming
interface to the disk: how do you need to modify the block-device
abstraction if you want the disk to have more control over allocation
policies?

In article <19990321174436.A23634@chelm.cs.nmt.edu>,
yodaiken@chelm.cs.nmt.edu adds:

> On Sun, Mar 21, 1999 at 12:16:40PM -0800, Matthew Jacob wrote:
>> Then there was "Enriching the File System-Storage System Interface"
>> work-in-progress (Drew Roselli, Jeanna Neefe Matthews, Tom Anderson
>> (drew@cs.berkeley.edu) which talked about informing the storage subsystem
>> with info hints as for file block lifetime, etc... I think this might have
>> been what you were thinking of?

> I think this is what Jim must have had in mind. Tell the disk drive which
> blocks are related, which blocks are unlikely to be written, ... so that the
> drive can optimize geometry. If I'm not mistaken, sct said that ext3 will
> support this kind of thing.

Not necessarily ext3, but it _is_ something we have been discussing.
In particular, there are good reasons to want to remove some of the
allocation policy out of the filesystem for reasons other than pure
performance. If we want a decent LVM system in which we can easily
grow and shrink filesystems, it makes sense to do at least some of the
allocation legwork at a level nearer to the block device abstraction,
and Ingo and I have talked a bit about what such a filesystem/LVM
interaction might look like.

Especially with the prospect in sight of merging the LVM and Raid
codebases on Linux, this becomes very attractive. Today, ext2fs has
essentially only two allocation goals it can use: "try to allocate
these blocks sequentially", and "try to allocate these two things
close by because they are in the same directory". Both of those are
pretty easy to abstract out.

If the LVM layer can deal with those demands, then expanding a
filesystem becomes trivial: the LVM simply stops returning "ENOSPACE"
to allocation requests and starts returning new space (not necessarily
indexed by block numbers). If the filesystem can also deallocate such
space, then we have an abstraction behind which filesystem shrinking
is simple. Moreover, the software-raid side of the LVM can optimise
sequential allocations based on whatever criteria were determined when
the raid array was set up, to improve sequential bandwidth or to
maximise concurrent IOs.

Lots of food for thought for the future, but the common thread is that
for performance, you dont't want to do too much "intelligent"
scheduling/allocation at the higher levels of abstraction. There are
too many things --- raid arrays, LVM systems, even networks --- which
can get between the filesystem and the platters holding the data.

--Stephen


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:50    [W:1.183 / U:0.164 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site