Re: File System conversion -- ideas

[rmoser]

*********** REPLY SEPARATOR  ***********

On 6/29/2003 at 9:51 PM [e-mail] wrote:

>On Sun, Jun 29, 2003 at 04:29:45PM -0400, rmoser wrote:
>
>> NO!  You're not getting the point at all!
>>
>> You don't need a pair!  If you have 10 filesystems, you need 10 sets of
>> code in each direction, not 90.  You convert from the data/metadata set
>> in the first filesystem to a self-contained atom, and then back from the
>
>[snip handwaving]
>
>> That would be much harder to maintain as well.  It would have to be
>altered
>> every time the filesystem code in the kernel is changed.
>
>Not really, as long as filesystem _layout_ is stable.
>

Maybe heh.

>> I've beaten the O((FS_COUNT)^2) already.  And by the way, it's
>> O((FS_COUNT)*(FS_COUNT - 1_).  There's exactly O(2*FS_COUNT)
>> and o(2*FS_COUNT) sets of code needed total to be able to convert
>> between any two filesystems.
>
>No, you have not.  You are yet to demonstrate that it's doable.
>
>> Now, what's impractical is maintaining two sets of code that do exactly
>> the same thing.  Why maintain code here to read the filesystems, and
>> also in the kernel?  Just do it in the kernel.  Don't lose sight of the
>fact
>> that the final goal (after all else is done) is to modify VFS to actually
>> run this thing as a filesystem.  THAT is what's going to be a bitch.  The
>> conversions are simple enough.
>
>The *SHOW* *THEM*.  You keep repeating that it's simple.  Fine, show that
>it can be done.  Then we can start talking about the rest - until you can
>demonstrate (as in, show the working code) that does what you call simple,
>there is no point in going any further.
>

I'm not coding it.  I wish I could.  heh.  Hmm.... :/  I can't keep the wheels in
my head from cranking out ideas on how to structure the datasystem though
 :/  I'll go diagram that out for a start I guess.

>_That_ is the point of contention.  And no, saying the word "atom" does
>not count as proof of feasibility.  Show how to map metadata between
>different
>filesystem types.  Hell, show that you know what types of metadata are
>there.
>

heh.  Right-o.  Need to find out about filesystem structure...

>Forget about in-core data structures.  Whatever data structures you use,
>it boils down to manipulating on-disk ones - that's kinda the point of
>exercise, right?  Show what should be done with them - with whatever
>in-core
>objects you like.  Assuming that VFS or any other parts of kernel do not
>get into your way and do not impose any restrictions - how would you do
>this
>stuff?  From one on-disk layout to another.  In details.  Then we can go
>and see how to make existing kernel objects live with that.  That will be
>extra condition and it will only make the problem harder.  Until you have
>a solution of easier problem, there's no sense in discussing harder one.

Yeah, I know.  I always do keep the harder problem in mind, though, when
I intend to build it upon the easier problem.  The reason is that I want to
make sure the design isn't going to get in the way once the easier part is
solved.

well I'll go play.

--Bluefox Icy