erik quanstrom wrote:
So what about having venti on an AoE device, and fossil on a local drive
(say an ssd even)?
sure. we keep the cache on the coraid sr1521 as well.
How would you handle (or: how would venti handle), a
resize of the AoE device?
that would depend on the device structure of ken's fs.
as long as you don't use the pseudo-worm device, it wouldn't
care. the worm would simply grow. if you use the pseudo-worm
device (f), changing the size of the device would fail since
the written bitmap is at a fixed offset from the end of the
device. and if you try to read an unwritten block, the f
panics the file server. i stopped using the f device.
- erik
I am going to try my hands at beating a dead horse:)
So when you create a Venti volume, it basically writes '0's' to all the
blocks of the underlying device right? If I put a venti volume on a AoE
device which is a linux raid5, using normal desktop sata drives, what
are my chances of a successful completion of the venti formating (let's
say 1TB raw size)? Have you ever encountered such problems, or are you
using more robust hardware?
I ask because I have in the past, failed a somewhat-used sata drive
while creating a venti volume (it subsequently created i/o errors on
every os I used on it, although it limped along). I must say it is
quite a brutal process, creating venti (at least I get that impression
from the times I have done it in the past).
If linux is my raid controller, I know that it is _very_ picky about how
long a drive takes to respond and will fail a drive if it has to wait
too long.
By the way I am currently buying a few pieces of cheap hardware to
implement my own diskless fileserver. Should be ready to go in about a
couple of weeks.
-Jack
