Messages in this thread | | | Date | Sun, 29 Jun 2003 17:07:18 -0400 | From | rmoser <> | Subject | Re: 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/
| |