Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 17 Mar 2003 20:32:17 -0800
From:      Terry Lambert <tlambert2@mindspring.com>
To:        Jeff Roberson <jroberson@chesapeake.net>
Cc:        Brooks Davis <brooks@one-eyed-alien.net>, Julian Elischer <julian@elischer.org>, Alfred Perlstein <bright@mu.org>, FreeBSD current users <current@FreeBSD.ORG>, fs@FreeBSD.ORG
Subject:   Re: Anyone working on fsck?
Message-ID:  <3E76A151.320A1E12@mindspring.com>
References:  <20030317230147.I66343-100000@mail.chesapeake.net>

next in thread | previous in thread | raw e-mail | index | archive | help
Jeff Roberson wrote:
> On Mon, 17 Mar 2003, Terry Lambert wrote:
> > Jeff Roberson wrote:
> > > On Mon, 17 Mar 2003, Brooks Davis wrote:
> > > > I am still intrested in improvements to fsck since I'm planning to buy
> > > > several systems with two 1.4TB IDE RAID5 arrays in them soon.
> > >
> > > For these types of systems doing a block caching layer with a prefetch
> > > that understands how many spindles there are would be a huge benefit.
> >
> > I call that layer "Vinum" or "RAIDFrame", since that's a job I
> > expect that code to do for me.  8-).
> 
> They are not responsible for data caching.  Only informing the upper
> layers how many spindles they have.  Software RAID should be a transform
> only in my opinion.  There is no reason to have duplicate block caches in
> system memory.

Let's turn that around: "There is no reason to have duplicate spindle
knowledge".

Actually, I was not suggesting duplicate block caches, I was suggesting
cache attribution by spindle by the code that knows what block lives on
what spindle.

Even so, for RAID, this is generally problematic, because there's
multiple locations for the block: where it lives, where it's mirrored,
where it's parity block lives, etc..  Ideally, these are all different
spindles, so the problem can't be fixed by a simple cache.  8-(.  You
would need a chain of spindle references, supplied by the code that
knows the spindle, hung off the cache object.

Gets ugly fast.

-- Terry

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?3E76A151.320A1E12>