Re: reiser4 plugins (was: silent semantic changes with reiser4)
On Sat, Aug 28, 2004 at 04:05:02PM +0400, Alexander Lyamin wrote: > > But one could even say VFS is integral part of a linux filesystem as > > it does most of the work a filesystem driver does in other operating > > systems. > > theres no "linux filesystem". there are "linux filesystems". > thanks god. a linux filesystem, not the linux filesystem, please read again. > But I it would be really grate if you'll elaborate your sentence with > example of VFS functionality (lack of it) on said "other operating systems" > and if you'll define "most of work". most trivial example is namespace locking, in *BSD, Windows, SVR4 and derivates it's done in the lowlevel filesystem. In plan9, Linux and soon DragonlyBSD it's done in the VFS. > > > P.S. I imagine, how much flamed it would be if reiser4 made any intensive > > > changes in linux VFS code... > > > > It really depends on how you sent them. If you had a big patch without > > explanations - sure. > It would work with small tweaks, but you just can take a look at reiser4 > code and you'll understand that it just could not be chopped in > "set of small patches" altough it could be documented better ofcourse, > but its really well commented already. > > some times, some approaches to some problems just would not work. You still haven't even bother explaining what you want to do. It's hard to argue against vague uncertainity.
Re: reiser4 plugins (was: silent semantic changes with reiser4)
Sat, Aug 28, 2004 at 01:51:04PM +0200, Christoph Hellwig wrote: > On Sat, Aug 28, 2004 at 03:46:28PM +0400, Alexander Lyamin wrote: > > Its work for me couple of months. there were few hiccups, but they got fixed > > quickly by [EMAIL PROTECTED] only ext2 partition is /boot cause of BIOS > > limitations. Yes, i use it with LVM2 and stuff... > > See the mails from Christophe in this thread. seen. noted. > > > breaks guaranteed fs semantics, it's not going in in either reiser4 or > > > the vfs. > > A > > > > > > Al has started a thread to hash out working semantics, but there's not been > > > a single namesys person involved. Similar all of you have absolutely ignore > > Al message had a reply. > > "namesys persons" is Hans Reiser. Sufficient ? > > http://marc.theaimsgroup.com/?t=10935558262&r=1&w=2 > > I can't see Hans anywhere. And honestly Hans has been so out of touch > with VFS internals that some person actually understanding the issue > might be helpfull. That would probably whoever has taken over Nikita's > position. I assume Vladimir Saveliev could play this out... -- "the liberation loophole will make it clear.." lex lyamin
Re: reiser4 plugins (was: silent semantic changes with reiser4)
Sat, Aug 28, 2004 at 01:12:33PM +0200, Christoph Hellwig wrote: > On Sat, Aug 28, 2004 at 02:59:29PM +0400, Alexander Lyamin wrote: > > Thu, Aug 26, 2004 at 03:24:39PM +0200, Christoph Hellwig wrote: > > > This VFS interface is an integral part of ??very filesystem, and it > > > > VFS never was "an integral part" of ANY filesystem. my dog knows it. > > its just unified INTERFACE TO any filesystem (including reiser4). > > You's misquoting me. IF you quoted the whole context it'd be pretty > sure that the part of the filesystem that intefaces with the VFS is > meant. No. Its not me "misquoting", its just someone sound plain ?incoherrent?. Even if I overquoted reply with whole message, its still sound ?incohherent?. > > But one could even say VFS is integral part of a linux filesystem as > it does most of the work a filesystem driver does in other operating > systems. theres no "linux filesystem". there are "linux filesystems". thanks god. But I it would be really grate if you'll elaborate your sentence with example of VFS functionality (lack of it) on said "other operating systems" and if you'll define "most of work". > > > P.S. I imagine, how much flamed it would be if reiser4 made any intensive > > changes in linux VFS code... > > It really depends on how you sent them. If you had a big patch without > explanations - sure. It would work with small tweaks, but you just can take a look at reiser4 code and you'll understand that it just could not be chopped in "set of small patches" altough it could be documented better ofcourse, but its really well commented already. some times, some approaches to some problems just would not work. -- "the liberation loophole will make it clear.." lex lyamin
Re: reiser4 plugins (was: silent semantic changes with reiser4)
On Sat, Aug 28, 2004 at 03:46:28PM +0400, Alexander Lyamin wrote: >Not true. If true - send bugreports. Hate to say it, but apparently symlinking out of metas oopses, but that should be trivial to fix? >> Al has started a thread to hash out working semantics, but there's not been >> a single namesys person involved. Similar all of you have absolutely ignore >Al message had a reply. >"namesys persons" is Hans Reiser. Sufficient ? Not to be disrespectful, but Hans has sometimes taken personal shots on the lists and that's not a productive approach. Not that he'd be the only one around to do so. Seems to me, as Christoph said, that some other Namesys guy than Hans should participate in the Al/Linus branch of the thread with ideas. Certainly the VFS may have to be extended right about now, so someone who knows the exact details of Reiser4 should offer ideas and I'm not so sure it's Hans. Looks like he had the ideas but not the implementation. There's also the risk that Reiser4's implementation's don't really bend into even a modified/extended VFS because of the plugins? That's definitely something that has to be approached properly... -- mjt
Re: reiser4 plugins (was: silent semantic changes with reiser4)
On Sat, Aug 28, 2004 at 03:46:28PM +0400, Alexander Lyamin wrote: > Not true. If true - send bugreports. > > Its work for me couple of months. there were few hiccups, but they got fixed > quickly by [EMAIL PROTECTED] only ext2 partition is /boot cause of BIOS > limitations. Yes, i use it with LVM2 and stuff... See the mails from Christophe in this thread. > > breaks guaranteed fs semantics, it's not going in in either reiser4 or > > the vfs. > A > > > > Al has started a thread to hash out working semantics, but there's not been > > a single namesys person involved. Similar all of you have absolutely ignore > Al message had a reply. > "namesys persons" is Hans Reiser. Sufficient ? http://marc.theaimsgroup.com/?t=10935558262&r=1&w=2 I can't see Hans anywhere. And honestly Hans has been so out of touch with VFS internals that some person actually understanding the issue might be helpfull. That would probably whoever has taken over Nikita's position.
Re: reiser4 plugins (was: silent semantic changes with reiser4)
Sat, Aug 28, 2004 at 01:22:55PM +0200, Christoph Hellwig wrote: > On Sat, Aug 28, 2004 at 03:18:07PM +0400, Alexander Lyamin wrote: > > Yes, I think it would be nice to have this infrastructure in VFS. Technically. > > But its not possible, cause of "committee clusterfuck". Socially. Stupidly. > > Please explain your problems. I've not seen a single actually working > proposal yet. Current reiser4 implementation apparently oopses and Not true. If true - send bugreports. Its work for me couple of months. there were few hiccups, but they got fixed quickly by [EMAIL PROTECTED] only ext2 partition is /boot cause of BIOS limitations. Yes, i use it with LVM2 and stuff... de facto its even more stable then reiserfs 3.6, which got issues with CONFIG_PREEMPT. > breaks guaranteed fs semantics, it's not going in in either reiser4 or > the vfs. A > > Al has started a thread to hash out working semantics, but there's not been > a single namesys person involved. Similar all of you have absolutely ignore Al message had a reply. "namesys persons" is Hans Reiser. Sufficient ? > every single technical question or comment but started a flamefest > consisting mostly of personal attacs and "mine is longer" politics. no need to comment on this. -- "the liberation loophole will make it clear.." lex lyamin
Re: reiser4 plugins (was: silent semantic changes with reiser4)
On Sat, Aug 28, 2004 at 03:18:07PM +0400, Alexander Lyamin wrote: > Yes, I think it would be nice to have this infrastructure in VFS. Technically. > But its not possible, cause of "committee clusterfuck". Socially. Stupidly. Please explain your problems. I've not seen a single actually working proposal yet. Current reiser4 implementation apparently oopses and breaks guaranteed fs semantics, it's not going in in either reiser4 or the vfs. Al has started a thread to hash out working semantics, but there's not been a single namesys person involved. Similar all of you have absolutely ignore every single technical question or comment but started a flamefest consisting mostly of personal attacs and "mine is longer" politics.
Re: reiser4 plugins (was: silent semantic changes with reiser4)
Thu, Aug 26, 2004 at 03:35:07PM +0200, Christophe Saout wrote: > Am Donnerstag, den 26.08.2004, 15:24 +0200 schrieb Christoph Hellwig: > > > > First you say that that file-as-a-directory is crap then you say that it > > > does belong into the filesystem? > > > > I think you're talking about something different then me, I'm not > > talking about the magic meta files but the VFS interface in general. > > > > This VFS interface is an integral part of very filesystem, and it > > doesn't make a whole lot to put it into a plugin. > > Right. That's why these plugins are linked in uncoditionally. It doesn't > work without them. Hence "plugins" is not a very good name. its still plugins no matter what. they just emulate "conventional filesystem" behavior for VFS, but at some point you might want just to scrap VFS.. if you'd like to. And I honestly dont understand whats the other Christoph's worries are about. Its got perfomance. Its there. It can emulate "conventional filesystem" behaviour, for legacy apps. Thouse two that are currently crippled by metas, we are so happy arguing about, will get fixed fast. Thats a point where you could happily STOP and live with your happy "conventional filesystem emulation", yet enjoying perfomance aspects (if perfomance hurts you, do not compile reiserfs, just like one big-red distro does, nobody would not complain. except your hard-drive mechanics sick of seeks). But most people would not stop, and its good. Yes, I think it would be nice to have this infrastructure in VFS. Technically. But its not possible, cause of "committee clusterfuck". Socially. Stupidly. -- "the liberation loophole will make it clear.." lex lyamin
Re: reiser4 plugins (was: silent semantic changes with reiser4)
On Sat, Aug 28, 2004 at 02:59:29PM +0400, Alexander Lyamin wrote: >P.S. I imagine, how much flamed it would be if reiser4 made any intensive >changes in linux VFS code... Surely it would be flamefest galore, but thanks to Reiser4 there may be some VFS changes to that direction, maybe completely from Reiser4. Should keep some people at bay if the chances weren't so much replacing VFS than extending it. -- mjt
Re: reiser4 plugins (was: silent semantic changes with reiser4)
On Sat, Aug 28, 2004 at 02:59:29PM +0400, Alexander Lyamin wrote: > Thu, Aug 26, 2004 at 03:24:39PM +0200, Christoph Hellwig wrote: > > This VFS interface is an integral part of ??very filesystem, and it > > VFS never was "an integral part" of ANY filesystem. my dog knows it. > its just unified INTERFACE TO any filesystem (including reiser4). You's misquoting me. IF you quoted the whole context it'd be pretty sure that the part of the filesystem that intefaces with the VFS is meant. But one could even say VFS is integral part of a linux filesystem as it does most of the work a filesystem driver does in other operating systems. > P.S. I imagine, how much flamed it would be if reiser4 made any intensive > changes in linux VFS code... It really depends on how you sent them. If you had a big patch without explanations - sure.
Re: reiser4 plugins (was: silent semantic changes with reiser4)
On Thu, Aug 26, 2004 at 06:14:19PM +0200, Christophe Saout wrote: > Ok, I see your point. aops. Sorry. > Looking at the code this could be done. The wrappers that dispatch the > operations are really small and call the plugin that is registered with > the inode of the mapping. Instead it could have directly set the > corresponding operations. Right. The wrappers are doing a few things > before calling the plugin. That could be done the other way round too. > But that's more of an implementation issue and could still be changed. I agree that it's an implementation issue. But it's also a good proof for how Hans tries to ignore all the existing infrastructure for various reasons.
Re: reiser4 plugins (was: silent semantic changes with reiser4)
Am Donnerstag, den 26.08.2004, 18:06 +0200 schrieb Christoph Hellwig: > Again, your confusing upper and lower plugins. For things happening > below the pagecache you could register different address_space > operations which sometimes makes sense. But you want e.g. different > inode_operations for directories vs symlinks vs files. Ok, I see your point. aops. Sorry. Looking at the code this could be done. The wrappers that dispatch the operations are really small and call the plugin that is registered with the inode of the mapping. Instead it could have directly set the corresponding operations. Right. The wrappers are doing a few things before calling the plugin. That could be done the other way round too. But that's more of an implementation issue and could still be changed. > Please read through some linux filesystem code, okay :) I'm partly familiar with that, I just either misunderstood you or wasn't really thinking (probably the latter...). signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: reiser4 plugins (was: silent semantic changes with reiser4)
On Thu, Aug 26, 2004 at 05:48:54PM +0200, Christophe Saout wrote: > > > I don't know, ask Hans. How could the VFS know it a filesystem wants to > > > do something specific with a file that is completely transparent to the > > > VFS? > > > > The VFS shouldn't, that the whole point. That's why it allows the > > filesystem to register different method tables for each object. > > Only the objects it can distinguish. Yes, every inode can have different operation vectors. Which is the smallest possible object the VFS knows about. > > ops->file= reiser4_file_operations; > > ops->symlink = reiser4_symlink_inode_operations; > > ops->special = reiser4_special_inode_operations; > > ops->dentry = reiser4_dentry_operations; > > ops->as = reiser4_as_operations; > > How could reiser4 register other operations for files that should be > stored encrypted or compressed? It's all under reiser4_file_operations. Again, your confusing upper and lower plugins. For things happening below the pagecache you could register different address_space operations which sometimes makes sense. But you want e.g. different inode_operations for directories vs symlinks vs files. Please read through some linux filesystem code, okay :)
Re: reiser4 plugins (was: silent semantic changes with reiser4)
Am Donnerstag, den 26.08.2004, 17:37 +0200 schrieb Christoph Hellwig: > > > compression or encryption must sit below the pagecache to work nicely, > > > and this hint things that usually sit at the pagecache level. But let's > > > assume you have a valid use for different file_operations, why don't you > > > simply add in different file_operations instead of adding another > > > internal dispatch layer? > > > > I don't know, ask Hans. How could the VFS know it a filesystem wants to > > do something specific with a file that is completely transparent to the > > VFS? > > The VFS shouldn't, that the whole point. That's why it allows the > filesystem to register different method tables for each object. Only the objects it can distinguish. > ops->file= reiser4_file_operations; > ops->symlink = reiser4_symlink_inode_operations; > ops->special = reiser4_special_inode_operations; > ops->dentry = reiser4_dentry_operations; > ops->as = reiser4_as_operations; How could reiser4 register other operations for files that should be stored encrypted or compressed? It's all under reiser4_file_operations. signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: reiser4 plugins (was: silent semantic changes with reiser4)
> > compression or encryption must sit below the pagecache to work nicely, > > and this hint things that usually sit at the pagecache level. But let's > > assume you have a valid use for different file_operations, why don't you > > simply add in different file_operations instead of adding another > > internal dispatch layer? > > I don't know, ask Hans. How could the VFS know it a filesystem wants to > do something specific with a file that is completely transparent to the > VFS? The VFS shouldn't, that the whole point. That's why it allows the filesystem to register different method tables for each object.
