Re: VFS design question
In article <[EMAIL PROTECTED]> you wrote: > I tried to make it clear that I am clearly lacking expertise in this > topic. I am currently working on a somewhat related topic and was hoping > to get some reactions that would point me in the right directions as it > is somewhat hard to judge the VFS design when you do not have prior > experience in writing a file system on your own. Nowhere did I ask for a > 10 paged review on the matter. VFS abstraction is not too limiting, because the interface to user space is fixed by posix or other standards in the libc. So als long as the new filesystem want to support that semantic, it is not really limited. There are some cases which are a bit hard, for example inode numbers - especially when you want to provice NFS support, but that is not specifically a VFS Problem. And: VFS has evolved over time, that is the advantage of open source, you can just include new functions in the old filesystems when you think you need to impriove the framework. That said, if you look at Reiser4 for example, there are some plug-in extensions which are not yet possible in VFS, since it is a more high level interface... There are some different file close/lock semantics out there, and VFS does not even try to abstract them. gruss Bernd - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VFS design question
On Sat, 2007-05-19 at 11:06 -0700, H. Peter Anvin wrote: > Tobias Pflug wrote: > > Hi, > > > > A note in front: I realize that my question is rather broad and a bit > > vague, sorry for that :) > > > > The VFS is a great solution to transparently operate on different file > > systems by designating an interface for file systems that separates > > file system specific code from higher levels. > > > > Doesn't however this very feature also represent a limiting factor in > > some way? Surely you can map pretty much anything to the Common File > > System model, but is or has the VFS interface design been limiting > > in any way in contemporary file system design ? > > > > Why does this sound like "do my homework for me"? > > -hpa I tried to make it clear that I am clearly lacking expertise in this topic. I am currently working on a somewhat related topic and was hoping to get some reactions that would point me in the right directions as it is somewhat hard to judge the VFS design when you do not have prior experience in writing a file system on your own. Nowhere did I ask for a 10 paged review on the matter. Enough blablabla Any input would be welcome. Thanks. -Tobi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VFS design question
Tobias Pflug wrote: > Hi, > > A note in front: I realize that my question is rather broad and a bit > vague, sorry for that :) > > The VFS is a great solution to transparently operate on different file > systems by designating an interface for file systems that separates > file system specific code from higher levels. > > Doesn't however this very feature also represent a limiting factor in > some way? Surely you can map pretty much anything to the Common File > System model, but is or has the VFS interface design been limiting > in any way in contemporary file system design ? > Why does this sound like "do my homework for me"? -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
VFS design question
Hi, A note in front: I realize that my question is rather broad and a bit vague, sorry for that :) The VFS is a great solution to transparently operate on different file systems by designating an interface for file systems that separates file system specific code from higher levels. Doesn't however this very feature also represent a limiting factor in some way? Surely you can map pretty much anything to the Common File System model, but is or has the VFS interface design been limiting in any way in contemporary file system design ? thanks for your time. regards, Tobi PS: please CC I am not subscribed.thanks - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
VFS design question
Hi, A note in front: I realize that my question is rather broad and a bit vague, sorry for that :) The VFS is a great solution to transparently operate on different file systems by designating an interface for file systems that separates file system specific code from higher levels. Doesn't however this very feature also represent a limiting factor in some way? Surely you can map pretty much anything to the Common File System model, but is or has the VFS interface design been limiting in any way in contemporary file system design ? thanks for your time. regards, Tobi PS: please CC I am not subscribed.thanks - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VFS design question
Tobias Pflug wrote: Hi, A note in front: I realize that my question is rather broad and a bit vague, sorry for that :) The VFS is a great solution to transparently operate on different file systems by designating an interface for file systems that separates file system specific code from higher levels. Doesn't however this very feature also represent a limiting factor in some way? Surely you can map pretty much anything to the Common File System model, but is or has the VFS interface design been limiting in any way in contemporary file system design ? Why does this sound like do my homework for me? -hpa - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VFS design question
On Sat, 2007-05-19 at 11:06 -0700, H. Peter Anvin wrote: Tobias Pflug wrote: Hi, A note in front: I realize that my question is rather broad and a bit vague, sorry for that :) The VFS is a great solution to transparently operate on different file systems by designating an interface for file systems that separates file system specific code from higher levels. Doesn't however this very feature also represent a limiting factor in some way? Surely you can map pretty much anything to the Common File System model, but is or has the VFS interface design been limiting in any way in contemporary file system design ? Why does this sound like do my homework for me? -hpa I tried to make it clear that I am clearly lacking expertise in this topic. I am currently working on a somewhat related topic and was hoping to get some reactions that would point me in the right directions as it is somewhat hard to judge the VFS design when you do not have prior experience in writing a file system on your own. Nowhere did I ask for a 10 paged review on the matter. Enough blablabla Any input would be welcome. Thanks. -Tobi - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VFS design question
In article [EMAIL PROTECTED] you wrote: I tried to make it clear that I am clearly lacking expertise in this topic. I am currently working on a somewhat related topic and was hoping to get some reactions that would point me in the right directions as it is somewhat hard to judge the VFS design when you do not have prior experience in writing a file system on your own. Nowhere did I ask for a 10 paged review on the matter. VFS abstraction is not too limiting, because the interface to user space is fixed by posix or other standards in the libc. So als long as the new filesystem want to support that semantic, it is not really limited. There are some cases which are a bit hard, for example inode numbers - especially when you want to provice NFS support, but that is not specifically a VFS Problem. And: VFS has evolved over time, that is the advantage of open source, you can just include new functions in the old filesystems when you think you need to impriove the framework. That said, if you look at Reiser4 for example, there are some plug-in extensions which are not yet possible in VFS, since it is a more high level interface... There are some different file close/lock semantics out there, and VFS does not even try to abstract them. gruss Bernd - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
