Re: removing duplicate code

From: Robert Collins <robertc@dont-contact.us>
Date: 12 Oct 2002 19:57:02 +1000

On Sat, 2002-10-12 at 19:51, Henrik Nordström wrote:
> On 12 Oct 2002, Robert Collins wrote:
>
> > Yes,
> > IMO in the long run it should be as follows:
> > aufs, diskd go away.
> > ufs gets the ufscommon code again.
> >
> > The aufs and diskd and ufs disk access logic become diskio modules, not
> > cache_dir modules. Then the ufs store takes a parameter - which diskio
> > module to use.
>
> I think having the common directory as a library is fully sufficient for
> the purpose.
>
> Trying to abstract into "directory management module" and "iomodule" is
> probably too much effort, and I see such move more likely to paint
> yourself into a corner than any real benefits. If you only consider the
> "plain-stupid-simple" ioimplementations we have today then sure there may
> appear to be a benefit, but when you start looking into macro I/O
> operations then the boundary becomes fuzzy. Should perhaps also mention
> that some of the blocking ufscommon directory management code really
> should to be made aufs specific for the aufs store..

I agree that this should be done. I disagree about the painting into
corner though. Nearly every function outside the actual io queueing is
identical between diskd/aufs/ufs. There are minor differences, easily
addressible via template methods. (Not C++ templates, the template
method pattern). Still, as long as each step makes sense, we will see
where we get to :}.
 
> What should perhaps be a separate module is the index management today
> done in the core code, but I am not convinced on this either.. probably a
> internal library is more appropriate there too. When you start looking at
> more advanced stores then the boundary between index management and I/O
> becomes more and more fuzzy.

MM, I haven't really thought about this angle.

Rob

Received on Sat Oct 12 2002 - 03:57:06 MDT

This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:16:55 MST