lkml.org 
[lkml]   [2003]   [Jun]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: File System conversion -- ideas


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

    On 6/29/2003 at 9:51 PM viro@parcelfarce.linux.theplanet.co.uk 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

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 13:46    [W:3.961 / U:0.480 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site