Subject: Re: Google Summer of Code project ideas
To: None <tech-kern@NetBSD.org>
From: Edward B. DREGER <eddy+public+spam@noc.everquick.net>
List: tech-kern
Date: 04/23/2006 22:01:14
Sorry to respond to my own post.  I had a few more thoughts.

Terminology note: chunks resemble cyl groups, and contain blocks

The disk still should be segmented into several chunks.  Limiting
factor: keeping individual inode files small enough such that heapify
ops would be isolated to a(n) <n> kB area.

Direct inode files could use 16-bit offsets from base.  A 16 kB inode
file would contain up to 4096 inodes (start+end), capable of addressing
2 MB using blocks as small as 512 bytes.

Multi-chunk files?  With 2 MB chunks, seek time should be minimal
compared to transfer.  On a heavily-loaded system, full-chunk I/O
requests probably would need to be broken for friendly muxed behavior.

As for large-file allocation:  What about a single level of indirection?
A "super-inode" file of up to (2 MB - 16 kB) could reference ~0.25
million 64-bit cylinder groups.

~0.25E+6 * ~2 MB = ~0.5 TB max file size

Adjusting the inode-file size to 8 kB or 32 kB would alter the
indirection boundary and the maximum file size to ~0.125 TB or ~2 TB,
respectively.  Note further that minimum block size affects both the
i.b. and the max file size... if someone is concerned about hitting the
0.5 TB file limit, they probably don't need 512-byte granularity.

The problem now becomes selecting one chunk from many.  What about a
"master heap" that stores the head of each chunk's heap?  Another bit of
indirection, but only a single level.


Thinking out loud again...
Eddy
--
Everquick Internet - http://www.everquick.net/
A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/
Bandwidth, consulting, e-commerce, hosting, and network building
Phone: +1 785 865 5885 Lawrence and [inter]national
Phone: +1 316 794 8922 Wichita
________________________________________________________________________
DO NOT send mail to the following addresses:
davidc@brics.com -*- jfconmaapaq@intc.net -*- sam@everquick.net
Sending mail to spambait addresses is a great way to get blocked.
Ditto for broken OOO autoresponders and foolish AV software backscatter.