Messages in this thread | | | Date | Sat, 28 Aug 2004 12:11:14 -0400 | Subject | Re: reiser4 plugins (was: silent semantic changes with reiser4) | From | Jan Harkes <> |
| |
On Sat, Aug 28, 2004 at 03:18:07PM +0400, Alexander Lyamin wrote: > And I honestly dont understand whats the other Christoph's worries are about.
I honestly don't understand what all this 'grassroot' campaining is all about. Very valid technical points have been made and mostly ignored.
The whole 'it breaks backups' noise is just that, noise.
- It breaks VFS locking rules. - It pretends to provide a uniform way to store streams or metadata. However it only does so files and not for directories, symlinks, fifos, unix domain sockets, or device nodes, which makes it less than uniform. - From what I saw in one part of the discussion, it allows for infinite depth recursion (file/metas/metas/metas/...). Some applications are going to have a lot of fun with that.
And finally,
- When reiserfs3 got merged, it introduced iget3 and read_inode2 in the VFS layer. Later on when I started to use them for Coda I almost immediately found serious consistency problems, resulting in the iget4_locked implementation in the 2.5 kernels.
I don't think anyone ever fixed that race in reiser3. It should hit occasionally on concurrent lookups on SMP or preempt kernels. In 2.4, Coda needed a semaphore to prevent concurrency during the iget3 lookup until the new inode is actually initialized.
> Its got perfomance. Its there. It can emulate "conventional > filesystem" behaviour, for legacy apps.
So does ramfs.
> Yes, I think it would be nice to have this infrastructure in VFS. > Technically. But its not possible, cause of "committee clusterfuck". > Socially. Stupidly.
It will get there, just consider it constructive criticism. If we can help resolve or refute the technical issues, all the better. We might even end up with improvements or extensions to the VFS or MM making life easier for everyone.
Jan
- 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/
| |