[Oberon] filesystem with directories ?
W B Hacker
wbh at conducive.org
Fri May 5 08:12:22 CEST 2006
Jack Johnson wrote:
> On 5/4/06, Brantley Coile <brantley at coraid.com> wrote:
> Yep, that's definitely where I originally got the notion of using
> hashes as filenames. Venti's use at a block level is definitely more
> disk-efficient, but something like git is pretty easy to implement
> (even given my meager skills), given an existing filesystem and some
> monkeying around with the file calls.
> Where I would be tempted to upend the git model is to dispense with
> the tree object altogether and implement the tagging discussed
> earlier, though it could be interesting to come up with a system that
> would work equally well given a hierarchical view or a tagged view. I
> suppose the underlying system needn't be mutually exclusive.
In fact, (torn-tape aside) I don't suppose it ever was " ...
From card-decks thru IBM TOS, the storage has nearly always
been some form of 'block mode', relying either on
de-facto/de-jure ISAM, (cards & tape), a huge amount of sorts
and merges, (early Disk OS) or - what has largely survived -
some form of intermediate block listings, (bit-map, FAT) raw
lists, linked lists (hpfs?), table-driven, or ... whatever.
As said before - the so-caled "hierarchical fs' has almost never
been such anyway - it is just the human-friendly notational
convention imposed on the lists of blocks.
What we are looking at with Plan 9 'Venti', 'git', Google and
other search engines, - and in this thread - is challenging what
has come to be regardes as 'human friendly'.
There are several orders of magnitude more processing power and
storage capacity ubiquitously available than were in reach when
most of the common fs architectures came into being.
So - IMNSHO - the time is ripe for even a "lean" OS to embrace
the reality that one can no longer even buy 'small' storage
devices (look at USB stick capacity for example), or 'slow' CPU
(mobile phones outperform yesteryear's 'workstations'), bite the
fs bullet, and seek to implement a more easily scalable paradigm.
More information about the Oberon