Messages in this thread | | | From | "Stephen C. Tweedie" <> | Date | Tue, 23 Mar 1999 00:43:41 +0000 (GMT) | Subject | Re: [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/
| |