RE: what is squidng

> "Chemolli Francesco (USI)" wrote:
> >
> > > I found the reiserfs discussions interesting not from a
> > > reiserfs perspective
> > > but from the buffer cache/syscall interface/disk layout
> perspective.
> > > Personally, I still think a much simpler FS would suffice but
> > > since I'm busy
> > > improving the *REST* of squid so a fast FS would be useful,
> > > I'm not going
> > > to complain about other peoples work.. :-)
> >
> > If we're crazy enough, we could just as well design
> > our own filesystem, to be used on raw devices a la
> > Oracle (or most other DB engines)...
> > Linux's upcoming Tux2 filesystem seems quite cool as far as
> > consistency goes, and maybe it could be used as a basis.
> > But I'm daydreaming...
>
> Hans Reiser has made some pretty convincing arguments in favor of the
> tree based structure of ReiserFS. The packing code is
> already in place
> in the form of tail packing...all it needs now is locality with
> intelligence (plus some other stuff that Hans talked about in a thread
> on SquidNG which I'll dig up and forward here).

Tux2 (by Daniel Phillips)_is_ tree-based.
It is not journaled, but it is designed in a manner such that the
filesystem changes state atomically (using something that the author
calls "phase-three algorithm".
There are apparently a few patenting issues to be solved first (they're
checking for specific patents by Network Appliance), but everybody
in the linux-kernel mailing list is very excited about it.

> The only negative of moving forward with ReiserFS as a Squid object
> store, is that we sometimes have to wait for things in ReiserFS, as they
> have to answer both the general case, and the Squid case.

ReiserFS has something that we wouldn't need in Squid. Most of the metadata
stuff is pretty useless, and for our purposes we could just as well
only have the root-directory if (how it is with ReiserFS) searches
in a dir are very fast.
Furthermore, we don't need file types, permission bits or ids, and we
can be very lenient with state (as long as we can check that it
is valid, possibly in the background).

> So some of
> the things that Squid desperately needs for a fast filesystem won't be
> able to be done in the current ReiserFS...but in Reiser4, which begins
> devel relatively soon, I hope. The benefit, however, is that
> we get the
> help of an entire team (a seemingly ever growing team, at that) of
> coders to find bugs and work out how things should work.

True. But, as I said above, we need a very much stripped-down filesystem.

> Then again, a SquidFS could be somewhat simpler...thus requiring less
> eyes and hands to make it work well and stable. Really, if I hadn't
> seen Sizif produce a really great raw interface and some nice
> optimizations in a matter of a couple of months, I would have probably
> come down on the side of a dedicated SquidFS rather than a general
> purpose one with modifications...but I have seen it, so I'm
> pulling for
> a Reiser-based Squid object store.

Should we incorporate the sources (assuming that they're not too heavily
dependent on the Linux sources) or should this be a Linux-only optimization?

I'm just musing, of course. I don't have the time to code anything, so my
words
weight just about as an ant...

-- 
	/kinkie