Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 1 Oct 2000 05:29:52 +0200
From:      "Karsten W. Rohrbach" <karsten@rohrbach.de>
To:        Terry Lambert <tlambert@primenet.com>
Cc:        freebsd-fs <freebsd-fs@FreeBSD.ORG>
Subject:   Re: Journaling Filesystems in bsd?  (LFS, anyone?)
Message-ID:  <20001001052952.F83678@rohrbach.de>
In-Reply-To: <200010010217.TAA18354@usr05.primenet.com>; from tlambert@primenet.com on Sun, Oct 01, 2000 at 02:17:17AM %2B0000
References:  <20001001040520.D83678@rohrbach.de> <200010010217.TAA18354@usr05.primenet.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert(tlambert@primenet.com)@Sun, Oct 01, 2000 at 02:17:17AM +0000:
> Karsten writes:
> > Marius Bendiksen(mbendiks@eunet.no)@Mon, Sep 25, 2000 at 02:40:21PM +0200:
> > [...]
> > > more proper such filesystem. Or, get someone to port WAFL, and get NVRAM.
> >
> > this would be an interesting thing. with all the negative points of
> > nvram you got a few good points in wafl design which might be of
> > interest when it comes to lots of disks carrying one filesystem:
> > a) metadata is contained in files
> > b) those files are successors, referenced by the last on-volume snap 
> > c) spreading the file system over a bunch of disks is easy, also without
> >    lvm by design
> > d) devices in a bunch can be different size
> > e) you can hot-grow the filesystem (if your hardware supports hot-plug)
> > f) you can have as many files as you wish (or limit in your hashing
> >    structure) on a volume
> > g) linear write window over all devices
> > 
> > is netapp's wafl concept patented somehow?
> 
> There are three patents of which I'm aware.
could you be more specific, please?

> 
> That said, someone has already written a read-only WAFL FS for
> FreeBSD; it was announced to the FreeBSD FS list several weeks
> ago.
ahum, i obviously skipped over the mail it seems... is this available
for download somewhere? or perhaps already committed? ;-)

> 
> Another interesting concept is described in:
> 
> 	The Design and Implementation of a DCD Device Driver
> 	for UNIX
> 	Tycho Nightengale, Yiming Hu, Qing Yang
> 	1999 Usenix
> 	<http://www.usenix.org/events/usenix99/full_papers/nightingale/nightingale_html/>;
> 
> Ignore the fact that Jordan and I are thanked for a tiny amount
> of information at the end of the paper: it's a very good paper,
> anyway.  ;^)

i am sometimes thinking about a different concept of direct-attached
storage servers.
in other words, a setup like this one:

[service server (www,...)]
	|
	|  (1) <-- SCSI
	|
[storage server]
	|
	|  (2) <-- SCSI, 1 or more channels
	|
[disks (a lot)]

the basic idea is to implement a driver that creates a high-performance
block device on tail (1) which can be accessed as a giant scsi disk.
the inner workings of that disk should not be visible to the client, eg.
the service server (high volume web site, news, whatever).
given this abstrakt 'exported' block device, the storage server now can
utilize for example greg's vinum and (of course, since it's a cool idea) 
for example implement the dcd concept or hardware nvram or whatever you 
wish. bottom line is that the storage server is intelligent enough to do
a) strong buffering and intelligent scheduling of writes
b) adaptive read caching
c) provide high availability by soft/hardware instrumentation like vinum
   raid-5 code or dedicated controller hardware
while offloading most of the i/o processing load off the service server.

hm, this mail's now become nearly a paper, too ;-)

tell me what you think
/k
-- 
> Hackers do it with fewer instructions.
KR433/KR11-RIPE -- http://www.webmonster.de -- ftp://ftp.webmonster.de



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-fs" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20001001052952.F83678>