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 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 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)
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: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=10935558262r=1w=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: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)
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=10935558262r=1w=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)
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)
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)
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, 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 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.
