Re: reiser4 plugins
Hi Hans, Jeff Garzik wrote: > > We have to maintain said ugly code for decades. On 6/23/05, Hans Reiser <[EMAIL PROTECTED]> wrote: > No you don't, I do. Lots of people work on the kernel. If you wish to keep reiser4 maintenance to yourself, you probably need to keep it as a separate patch. Please consider submitting the non-controversial bits for merging first and then continue with the rest. It does not make a lot of sense reviewing the current patchkit as many parts of it won't be merged as is (e.g. the plugin stuff). Pekka
Re: -mm -> 2.6.13 merge status
Hi Hans,
On 6/22/05, Hans Reiser <[EMAIL PROTECTED]> wrote:
> I would in particular love to have you Andi Kleen do a full review of V4
> if you could be that generous with your time, as I liked much of the
> advice you gave us on V3.
Well, I am not Andi Kleen and this is not even in the ballpark of a full
review but here goes...
P.S. Would it be possible to have a version without the plugin stuff
submitted (and perhaps file as directory)? It would make much more
sense for the rest of us to review reiser4 without the most controversial
bits and get the bits that people agree on merged.
Pekka
> --- /dev/null 2003-09-23 21:59:22.0 +0400
> +++ linux-2.6.11-vs/fs/reiser4/pool.c 2005-06-03 17:49:38.668204642 +0400
> +/* initialise new pool */
> +reiser4_internal void
> +reiser4_init_pool(reiser4_pool * pool /* pool to initialise */ ,
> + size_t obj_size /* size of objects in @pool */ ,
> + int num_of_objs /* number of preallocated objects */ ,
> + char *data /* area for preallocated objects */ )
> +{
> + reiser4_pool_header *h;
> + int i;
> +
> + assert("nikita-955", pool != NULL);
These assertion codes are meaningless to the rest of us so please drop
them.
> --- /dev/null 2003-09-23 21:59:22.0 +0400
> +++ linux-2.6.11-vs/fs/reiser4/type_safe_hash.h 2005-06-03
> 17:49:38.751209197 +0400
> @@ -0,0 +1,320 @@
> +/* Copyright 2001, 2002, 2003 by Hans Reiser, licensing governed by
> + * reiser4/README */
> +
> +/* A hash table class that uses hash chains (singly-linked) and is
> + parametrized to provide type safety. */
This belongs to include/linux, not reiser4.
> --- /dev/null 2003-09-23 21:59:22.0 +0400
> +++ linux-2.6.11-vs/fs/reiser4/type_safe_list.h 2005-06-03
> 17:49:38.755209417 +0400
> @@ -0,0 +1,436 @@
> +/* Copyright 2001, 2002, 2003 by Hans Reiser, licensing governed by
> reiser4/README */
> +
> +#ifndef __REISER4_TYPE_SAFE_LIST_H__
> +#define __REISER4_TYPE_SAFE_LIST_H__
> +
> +#include "debug.h"
> +/* A circular doubly linked list that differs from the previous
> +implementation because it is parametrized to provide
> + type safety. This data structure is also useful as a queue or stack.
This belongs to include/linux, not reiser4.
> --- /dev/null 2003-09-23 21:59:22.0 +0400
> +++ linux-2.6.11-vs/fs/reiser4/vfs_ops.c 2005-06-03 17:51:28.110210237
> +0400
> +/* ->get_sb() method of file_system operations. */
> +static struct super_block *
> +reiser4_get_sb(struct file_system_type *fs_type /* file
> + * system
> + * type */ ,
> +int flags /* flags */ ,
> +const char *dev_name /* device name */ ,
> +void *data /* mount options */ )
Please drop the useless parameter comments.
> +/*
> + * Initialization stages for reiser4.
> + *
> + * These enumerate various things that have to be done during reiser4
> + * startup. Initialization code (init_reiser4()) keeps track of what stage
> was
> + * reached, so that proper undo can be done if error occurs during
> + * initialization.
> + */
> +typedef enum {
> + INIT_NONE, /* nothing is initialized yet */
> + INIT_INODECACHE, /* inode cache created */
> + INIT_CONTEXT_MGR,/* list of active contexts created */
> + INIT_ZNODES, /* znode slab created */
> + INIT_PLUGINS,/* plugins initialized */
> + INIT_PLUGIN_SET, /* psets initialized */
> + INIT_TXN,/* transaction manager initialized */
> + INIT_FAKES, /* fake inode initialized */
> + INIT_JNODES, /* jnode slab initialized */
> + INIT_EFLUSH, /* emergency flush initialized */
> + INIT_FQS,/* flush queues initialized */
> + INIT_DENTRY_FSDATA, /* dentry_fsdata slab initialized */
> + INIT_FILE_FSDATA,/* file_fsdata slab initialized */
> + INIT_D_CURSOR, /* d_cursor suport initialized */
> + INIT_FS_REGISTERED, /* reiser4 file system type registered */
> +} reiser4_init_stage;
Please use regular gotos instead. This is a silly hack especially since you
don't have release function for all of the stages.
> +reiser4_internal void reiser4_handle_error(void)
> +{
> + struct super_block *sb = reiser4_get_current_sb();
> +
> + if ( !sb )
> + return;
> + reiser4_status_write(REISER4_STATUS_DAMAGED, 0, "Filesystem error
> occured");
> + switch ( get_super_private(sb)->onerror ) {
> + case 0:
> + reiser4_panic("foobar-42", "Filesystem error occured\n");
> + case 1:
> + if ( sb->s_flags & MS_RDONLY )
> + return;
> + sb->s_flags |= MS_RDONLY;
> + break;
> + case 2:
> + machine_restart(NULL);
Probably not
Re: [PATCH] [RESEND] ReiserFS _get_block_create_0 wrong behavior when I/O fails
Thanks fs, Edward, can you or vs look at this?
Hans
fs wrote:
>Seems my domain is filtered , so I resend the modified version.
>
>Related FS:
>ReiserFS
>
>Related Files:
>fs/reiserfs/inode.c
>
>Bug description:
>Make a ReiserFS partition in USB storage HDD, create a test file
>with
>enough size.
>Write a program, do: open(O_RDONLY) - read - close. After each
>operation, pause for a while, such as 3s. Between open and read, unlug
>the
>USB wire. open returns zero-filled buffer, no error returns.
>
>Bug analysis:
>do_mpage_readpage will call FS-specific get_block to get buffer
>mapped
>from disk. reiserfs_get_block doesn't return non-zero when I/O failure
>occurs.
>reiserfs_get_block -> _get_block_create_0 ->
>search_by_position_by_key
>search_by_position_by_key returns IO_ERROR, but the original code just
>simply
>returns 0
>
>research:
>if (search_for_position_by_key (inode->i_sb, &key, &path) !=
>POSITION_FOUND) {
>pathrelse (&path);
>if (p)
>kunmap(bh_result->b_page) ;
>// We do not return -ENOENT if there is a hole but page is
>uptodate, because it means
>// That there is some MMAPED data associated with it that is yet
>to be written to disk.
>if ((args & GET_BLOCK_NO_HOLE) &&
>!PageUptodate(bh_result->b_page) ) {
>return -ENOENT ;
>}
>return 0 ; <- 0 retuns for IO_ERROR
>}
>
>Way around:
>test result of search_for_position_by_key
>
>Signed-off-by: Qu Fuping<[EMAIL PROTECTED]>
>
>Patch:
>diff -uNp /tmp/linux-2.6.12-rc6/fs/reiserfs/inode.c
>/tmp/linux-2.6.12-rc6.new/fs/reiserfs/inode.c
>
>
>
>
>
>
>--- linux-2.6.12-rc6.old/fs/reiserfs/inode.c 2005-06-06 11:22:29.0
>-0400
>+++ linux-2.6.12-rc6.new/fs/reiserfs/inode.c 2005-06-17 16:12:18.0
>-0400
>@@ -254,6 +254,7 @@ static int _get_block_create_0 (struct i
> char * p = NULL;
> int chars;
> int ret ;
>+int result ;
> int done = 0 ;
> unsigned long offset ;
>
>@@ -262,7 +263,8 @@ static int _get_block_create_0 (struct i
> (loff_t)block * inode->i_sb->s_blocksize + 1, TYPE_ANY, 3);
>
> research:
>-if (search_for_position_by_key (inode->i_sb, &key, &path) !=
>POSITION_FOUND) {
>+result = search_for_position_by_key (inode->i_sb, &key, &path) ;
>+if (result != POSITION_FOUND) {
> pathrelse (&path);
> if (p)
> kunmap(bh_result->b_page) ;
>@@ -270,7 +272,8 @@ research:
> // That there is some MMAPED data associated with it that is yet to be
> written to disk.
> if ((args & GET_BLOCK_NO_HOLE) && !PageUptodate(bh_result->b_page) ) {
> return -ENOENT ;
>- }
>+ }else if(result == IO_ERROR)
>+ return -EIO;
> return 0 ;
> }
>
>@@ -382,7 +385,8 @@ research:
>
> // update key to look for the next piece
> set_cpu_key_k_offset (&key, cpu_key_k_offset (&key) + chars);
>- if (search_for_position_by_key (inode->i_sb, &key, &path) !=
>POSITION_FOUND)
>+ result = search_for_position_by_key (inode->i_sb, &key, &path);
>+ if (result != POSITION_FOUND)
> // we read something from tail, even if now we got IO_ERROR
> break;
> bh = get_last_bh (&path);
>@@ -394,6 +398,10 @@ research:
>
> finished:
> pathrelse (&path);
>+
>+if(result == IO_ERROR)
>+ return -EIO;
>+
> /* this buffer has valid data, but isn't valid for io. mapping it to
> * block #0 tells the rest of reiserfs it just has a tail in it
> */
>
>
Re: reiser4 plugins
Jeff Garzik wrote: > We have to maintain said ugly code for decades. No you don't, I do. >> filesystem, but if so, it will have to do it much more slowly. Take the >> good ideas -- things like plugins -- and make them at least look like >> incremental updates to the current VFS, and make them available to all >> filesystems. > > So, Reiser4 may eventually take over VFS and be the only Linux > > This is how all Linux development is done. > > The code evolves over time. > > You have just described the path ReiserFS needs to take, in order to > get this stuff into the kernel, in fact. You missed his point. He is saying ext3 code should migrate towards becoming reiser4 plugins, and reiser4 should be merged now so that the migration can get started. I don't really care whether ext3 uses our plugin model. (If it does, fine, please credit me for it though, and consider maybe a thank you. I am happy to thank the XFS team for the idea of delayed allocation) I am entitled to get some advantage from being the first on the block. Other fs maintainers don't want me to have that entitlement, so they add delays to slow us down. It is odd how Hellwig no longer describes himself as XFS associated. Did SGI and him > There is no entitlement to be merged in the upstream kernel. True, but what is interesting is that you don't think the faster filesystem should be merged, and the others should catch up to it later if they can, instead you think it should be delayed until all of its benefits can be transmitted to the other filesystems first so that everyone can be equal.
Re: reiser4 plugins
Christoph Hellwig wrote: > > > > >>What is wrong with having one file in the FS use a write only plugin, in >>which the encrypion key is changed with every append in a forward but >>not backward computable manner, and in order to read a file you must >>either have a key that is stored on another computer or be reading what >>was written after the moment of cracking root? >> >> > >Because root can read kernel memory this is completely useless :) > > You missed the point of it rather nicely. If root can read kernel memory, that only gets it the appends made after the point in time of cracking root. It is not my idea, and it is not yet present in our code, let me not seem to take credit for it though I think it a good idea.
Re: reiser4 plugins
Correct me if I am wrong: What exists currently in VFS are vector instances, not classes. Plugins, selected by pluginids, are vector classes, with each pluginid selecting a vector class. You propose to have the vector class layer (aka plugin layer) in reiser4 export the vector instance to VFS for VFS to handle for each object, rather than having VFS select reiser4 and reiser4 selecting a vector class (aka plugin) which selects a method. If we agree on the above, then I will comment further. Christoph Hellwig wrote: >On Wed, Jun 22, 2005 at 06:24:32PM +0400, Alexander Zarochentsev wrote: > > >>Reiser plugins are for the same. Would you agree with reiser4 plugin design >>if the plugins will not dispatch VFS object methods calls by themselves but >>set ->foo_ops fileds instead? I guess you don't like to have the two >>dispatching systems at the same level. >> >> > >That is exactly the point I want to make. I haven't looked at the design >in detail for a long time, but schemes to allow different object to have >different operation vectors is a good idea. We already have that to >varying degrees in all filesystems, and making that more formal is a good >thing. > > > >
Re: reiser4 plugins
David> Spotlight on the Mac. Users love it. We can do it. But David> not without changing something in the filesystem. David> Actually, I think we came up with several ways to do this, David> all of which required Reiser4 interfaces. It seems the existing Beagle project is a counterexample to this. In fact, to make things even more perfect, Beagle doesn't work on top of Reiser4. - R.
Re: reiser4 plugins
David Masover writes: [...] > > What we want is to have programs that can write small changes to one > file or to many files, lump all those changes into a transaction, and > have the transaction either succeed or fail. No existing file system guarantees such behavior. Even atomicity of single system call is not guaranteed. > > > it doesn't stop the system dead in its tracks waiting for some very long > > transaction to finish? > > We've also discussed this. For one thing, if we can have transactions > in databases which don't stop the database dead in its tracks, why can't > we do it with filesystems? Because to have such transactions databases pay huge price in both resource consumption and available concurrency (isolation, commit-time locks, etc.), and yet mechanism they use to deal with stuck transactions (which is simply to abort it) is not very suitable for the file system. > > But anyway, if you really want to know, ask someone else or read the > archives. I wasn't really paying attention except to remember that this > issue was resolved. That would be real breakthrough. [...] > > >> fibretions, etc, > > > > > > ??? > > Low-level tweaking. I think the word is from some sort of calculus. Fibration. http://marc.theaimsgroup.com/?l=linux-kernel&m=108032604606183&w=2 Nikita.
Re: reiser4 plugins
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Horst von Brand wrote: > Artem B. Bityuckiy <[EMAIL PROTECTED]> wrote: > >>Markus TЖrnqvist wrote: [...] >>> and move the stuff to the VFS as needed or >>>deemed necessary. And enable the pseudo interface, or at least >>>set it in menuconfig and enable by default, it needs testing too. > > > Then test it out of the standard tree... Standard tree is actually a good place to test things. That's why there are so many things there that say "EXPERIMENTAL", and so many of those don't work. Some even refuse to compile. >>atomic operations, > > > What is atomic that isn't in the standard filesystems? How do you guarantee We've been discussing this for quite awhile. In standard filesystems, the only things that are atomic are metadata. If I rename a file and crash, I'm guarenteed to either have renamed the file or not, and not be caught halfway. This does not apply to files. In fact, the only way to perform an atomic write on a file, using the filesystem's atomicity, is to write a new file, nuke the old one, and rename the new one on top of the old one. What we want is to have programs that can write small changes to one file or to many files, lump all those changes into a transaction, and have the transaction either succeed or fail. > it doesn't stop the system dead in its tracks waiting for some very long > transaction to finish? We've also discussed this. For one thing, if we can have transactions in databases which don't stop the database dead in its tracks, why can't we do it with filesystems? But anyway, if you really want to know, ask someone else or read the archives. I wasn't really paying attention except to remember that this issue was resolved. >> different kinds of stat data, > > > Usefulness? Sounds like kernel bloat leading to userspace bloat and > applications/users wondering what the heck goes on when they don't grok the > particular stat format. So you allow multiple stat formats. Bloat is not as big an issue here as the bloat of existing systems which run on top of the FS and don't cooperate. Gnome and KDE each have their own VFS, for instance. >> fibretions, etc, > > > ??? Low-level tweaking. I think the word is from some sort of calculus. >>etc. Some thing is not yet ready - doesn't matter. Some of this is of >>general interest, some is Reiser4-dedicated. > > > I don't see anything that would interest me at least, so you can safely > scratch the "general interest" part. You're the sole general public? >>New interfaces are needed to allow users to utilize that all. > > > That is a quite strong argument /against/ it all in my book. It means bloat > in /every/ filesystem, and they have shown to be able to do without for > some 30 years now. I'd need /very/ strong reasons for adding something. Spotlight on the Mac. Users love it. We can do it. But not without changing something in the filesystem. Actually, I think we came up with several ways to do this, all of which required Reiser4 interfaces. It's "bloat" until you need it. >> My point >>is that the things that are of general interest must not be >>Reiser4-only. > > > Reiser4-only stuff is of very limited use, if it isn't just internal > stuff. And that doesn't need any changes. Only it does. Reiser4 can't get into the kernel because it duplicates the VFS in order to extend it. It couldn't get in before because it extended the VFS directly. Maybe you just don't want this system to EVER get in, no matter what they do to it? >> For example, I should have a possibility to implement >>files-like-dir in _another_ FS using the same interfaces that Reiser4 >>uses. That's all I wanted to say. > > > It has been argued over and over that that particular feature /can't/ be > implemented sanely anyway, so it has to stay out. Besides not making any It's been dropped for the moment, but it's been argued just as many times that it can be done sanely. > sense. "You've got files and directories" is a bit asymetrical and so not > quite nice; "all you have is directories" is symmetrical, estetic, and > completely useless; "some files are directories, some aren't; files in > file-directories are different than regular files in directory-directories" > is just a mindless jumble. Or you can just say "There are no files. There are no directories. There are only objects, which contain a chunk of linear data and other objects." If you actually go read the whitepaper, you will discover that this is actually a cleaner, more esthetic, and more useful model than the current one. It's just a little harder to do. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQIVAwUBQrndSHgHNmZLgCUhAQKOCxAAlhBiu234fmMaUv7kYp0Xt1V2yjP67c8U ggUbB6
[PATCH] reiserfs: enable attrs by default if safe
The following patch enables attrs by default if the reiserfs_attrs_cleared
bit is set in the superblock. This allows chattr-type attrs to be used
without any further action by the user.
Signed-off-by: Jeff Mahoney <[EMAIL PROTECTED]>
diff -ruNpX dontdiff linux-2.6.12-rc6/fs/reiserfs/super.c
linux-2.6.12-rc6.devel/fs/reiserfs/super.c
--- linux-2.6.12-rc6/fs/reiserfs/super.c2005-06-13 14:34:58.0
-0400
+++ linux-2.6.12-rc6.devel/fs/reiserfs/super.c 2005-06-22 17:34:55.0
-0400
@@ -884,6 +884,8 @@ static void handle_attrs( struct super_b
reiserfs_warning(s, "reiserfs: cannot support
attributes until flag is set in super-block" );
REISERFS_SB(s) -> s_mount_opt &= ~ ( 1 <<
REISERFS_ATTRS );
}
+ } else if (le32_to_cpu( rs -> s_flags ) & reiserfs_attrs_cleared) {
+ REISERFS_SB(s)->s_mount_opt |= REISERFS_ATTRS;
}
}
--
Jeff Mahoney
SuSE Labs
[PATCH] reiserfs: Check if attrs are enabled for attr ioctls
ReiserFS currently will allow the user to set/get attrs for files regardless
if they are enabled. The patch checks to see if they are enabled, and returns
-NOTTY if they are not.
ext[23] doesn't need this check because attrs are always enabled.
Signed-off-by: Jeff Mahoney <[EMAIL PROTECTED]>
diff -ruNpX dontdiff linux-2.6.12-rc6/fs/reiserfs/ioctl.c
linux-2.6.12-rc6.devel/fs/reiserfs/ioctl.c
--- linux-2.6.12-rc6/fs/reiserfs/ioctl.c2005-06-13 14:34:32.0
-0400
+++ linux-2.6.12-rc6.devel/fs/reiserfs/ioctl.c 2005-06-22 17:30:40.0
-0400
@@ -34,10 +34,16 @@ int reiserfs_ioctl (struct inode * inode
/* following two cases are taken from fs/ext2/ioctl.c by Remy
Card ([EMAIL PROTECTED]) */
case REISERFS_IOC_GETFLAGS:
+ if (!reiserfs_attrs (inode->i_sb))
+ return -ENOTTY;
+
flags = REISERFS_I(inode) -> i_attrs;
i_attrs_to_sd_attrs( inode, ( __u16 * ) &flags );
return put_user(flags, (int __user *) arg);
case REISERFS_IOC_SETFLAGS: {
+ if (!reiserfs_attrs (inode->i_sb))
+ return -ENOTTY;
+
if (IS_RDONLY(inode))
return -EROFS;
--
Jeff Mahoney
SuSE Labs
Re: How to make Reiser4 plugins&namespace magic work?
It works! Thank you, Edward. :) В Срд, 22.06.2005, в 19:32, Edward Shishkin пишет: > >Andrew Morton mentioned that "patches still contain all the > >reiser4-specific namespace enhancements, only it is disabled, so it is > >effectively dead code" and it seems this explains why I didn't see any > >of Reiser4 namespace magic last time I've tried to play with it. > > > >But actually I want to see it and I want to play with it - any recipe > >for how to revive this code? > > > >Thanks. > > > > > > > Hello. > You might want to enable pseudo interface having > #define ENABLE_REISER4_PSEUDO (1) > in reiser4.h, build the kernel and read this paper: > http://thebsh.namesys.com/v4/pseudo.html > Note, that this paper is not updated, so use "" instead of "metas". > Also in order to use this interface for regular files the last ones > should have an executable flag. > > Thanks, > Edward. -- Roman ,---. ,--. / http://www.3os.ru/ Vhttp://www.osrc.info/ \ .o. \mailto: [EMAIL PROTECTED] ^ mailto: [EMAIL PROTECTED]/ ..o `---' `--' ooo gpg --recv-keys 0xE5E055C3 --keyserver hkp://subkeys.pgp.net signature.asc Description: Эта часть сообщения подписана цифровой подписью
[PATCH] reiserfsprogs: Warn on block sizes > 4k
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello all -
Filesystems created with block size > page size will not work until that
support is added to the kernel. Filesystems with block size > 4k (lowest
page size supported in Linux) will not work on all systems. This patch
adds a check and a warning in those conditions, informing the user of
the caveats of using a larger block size. It can be overridden with -f.
Patch attached, please apply.
- -Jeff
- --
Jeff Mahoney
SuSE Labs
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (GNU/Linux)
iD8DBQFCuaqrLPWxlyuTD7IRApVpAJ41vsbPZxZrLqp96kr1AJx0DETsCQCfTUOH
uW4BvvYQiYB4knnt6gdgn6A=
=bSZ+
-END PGP SIGNATURE-
Subject: [PATCH] reiserfsprogs: Warn on block sizes > 4k
From: Jeff Mahoney <[EMAIL PROTECTED]>
Filesystems created with block size > page size will not work until that
support is added to the kernel. Filesystems with block size > 4k (lowest
page size supported in Linux) will not work on all systems. This patch
adds a check and a warning in those conditions, informing the user of the
caveats of using a larger block size. It can be overridden with -f.
diff -ruNp reiserfsprogs-3.6.19/mkreiserfs/mkreiserfs.c reiserfsprogs-3.6.19.devel/mkreiserfs/mkreiserfs.c
--- reiserfsprogs-3.6.19/mkreiserfs/mkreiserfs.c 2004-09-30 23:04:21.0 +0200
+++ reiserfsprogs-3.6.19.devel/mkreiserfs/mkreiserfs.c 2005-06-22 19:26:58.221711866 +0200
@@ -684,6 +684,9 @@ int main (int argc, char **argv)
if (!(mode & QUIET_MODE) && !can_we_format_it (device_name, force))
return 1;
+
+if (!(mode & QUIET_MODE) && !block_size_ok (Block_size, force))
+return 1;
if (jdevice_name)
if (!(mode & QUIET_MODE) && !can_we_format_it (jdevice_name, force))
diff -ruNp reiserfsprogs-3.6.19/reiserfscore/reiserfslib.c reiserfsprogs-3.6.19.devel/reiserfscore/reiserfslib.c
--- reiserfsprogs-3.6.19/reiserfscore/reiserfslib.c 2004-10-04 22:39:35.0 +0200
+++ reiserfsprogs-3.6.19.devel/reiserfscore/reiserfslib.c 2005-06-22 20:07:38.015345826 +0200
@@ -1175,6 +1175,24 @@ void make_sure_root_dir_exists (reiserfs
&parent_root_dir_key, ih_flags);
}
+int block_size_ok (int blocksize, int force)
+{
+int pagesize = getpagesize();
+if (blocksize > 4096) {
+reiserfs_warning (stderr, "Block sizes larger than 4k are not "
+ "supported on all architectures.\n");
+if (blocksize > pagesize)
+reiserfs_warning (stderr, "The newly created filesystem will not "
+ "be mountable on this system.\n");
+else
+reiserfs_warning (stderr, "The newly created filesystem may not "
+ "be mountable on other systems.\n");
+check_forcing_ask_confirmation (force);
+}
+
+return 1;
+}
+
/* we only can use a file for filesystem or journal if it is either not
mounted block device or regular file and we are forced to use it */
No more penis enlarge ripoffs!
Expand your Penis 20% Larger in weeks http://www.retdehola.com/ss/ Do not throw the arrow which will return against you. I have read your book and much like it. Do definite good; first of all to yourself, then to definite persons. Intuition isn't the enemy, but the ally, of reason. It is easier to be critical than correct.
Re: reiser4 plugins
Artem B. Bityuckiy <[EMAIL PROTECTED]> wrote: > Markus TÐrnqvist wrote: > > So merge it as it is Fix it first. The "merge as it stands" just gives rise to stuff that is /never/ fixed properly. > > and move the stuff to the VFS as needed or > > deemed necessary. And enable the pseudo interface, or at least > > set it in menuconfig and enable by default, it needs testing too. Then test it out of the standard tree... > Reiser4 has a number of great (IMO) things like file as directory, Urgh. > atomic operations, What is atomic that isn't in the standard filesystems? How do you guarantee it doesn't stop the system dead in its tracks waiting for some very long transaction to finish? >different kinds of stat data, Usefulness? Sounds like kernel bloat leading to userspace bloat and applications/users wondering what the heck goes on when they don't grok the particular stat format. > fibretions, etc, ??? > etc. Some thing is not yet ready - doesn't matter. Some of this is of > general interest, some is Reiser4-dedicated. I don't see anything that would interest me at least, so you can safely scratch the "general interest" part. > New interfaces are needed to allow users to utilize that all. That is a quite strong argument /against/ it all in my book. It means bloat in /every/ filesystem, and they have shown to be able to do without for some 30 years now. I'd need /very/ strong reasons for adding something. > My point > is that the things that are of general interest must not be > Reiser4-only. Reiser4-only stuff is of very limited use, if it isn't just internal stuff. And that doesn't need any changes. > For example, I should have a possibility to implement > files-like-dir in _another_ FS using the same interfaces that Reiser4 > uses. That's all I wanted to say. It has been argued over and over that that particular feature /can't/ be implemented sanely anyway, so it has to stay out. Besides not making any sense. "You've got files and directories" is a bit asymetrical and so not quite nice; "all you have is directories" is symmetrical, estetic, and completely useless; "some files are directories, some aren't; files in file-directories are different than regular files in directory-directories" is just a mindless jumble. > The other question that it may be difficult to foresee everything and > it may make sense to move some things upper in future. Another good reason to keep it out ;-) -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, ChileFax: +56 32 797513
Re: reiser4 plugins
Vladimir Saveliev writes:
> Hello
>
> On Wed, 2005-06-22 at 18:28, Nikita Danilov wrote:
> > David Masover writes:
> >
> > [...]
> >
> > >
> > > Maintainability is like optimization. The maintainability of a
> > > non-working program is irrelevant. You'd be right if we already had
> > > plugins-in-the-VFS. We don't. The most maintainable solution for
> > > plugins-in-the-FS that actually exists is Reiser4, exactly as it is now
> > > - -- because it is the _only_ one that actually exists right now.
> >
> > But it is not so. There _are_ plugins-in-the-VFS. VFS operates on opaque
> > objects (inodes, dentries, file system types) through interfaces:
> > {inode,address_space,dentry,sb,etc.}_operations. Every file system
> > back-end if free to implement whatever number of these interfaces. And
> > the do this already: check the sources; even ext2 does this: e.g.,
> > ext2_fast_symlink_inode_operations and ext2_symlink_inode_operations.
> >
>
> imho, this is something different. Ext2 decides itself how to manage a
> symlink depending on length of string the symlink is to store.
> Reiser4 plugins are to allow a user to define himself which operations
> file is to be managed with.
I fail to see this as an important distinction:
- ext2decides what "plugin" to use based on parameters supplied to
the file creation system call;
- reiser4 decides what "plugin" to use based on parameters supplied to
the file creation system call.
>
> > This is exactly what upper level reiser4 plugins are for.
>
> > I guess that one of Christoph Hellwig's complaints is that reiser4
> > introduces another layer of abstraction to implement something that
> > already exists.
> >
>
> I do not think that it exists already.
> You can have standart type of files and that is all.
>
> Linux filesystem is not supposed to provide anything but plain
> regular/directory/symlinks/sockets/block device/char device/fifo files.
If you are talking about S_IFMT bits they are just a relic to keep user
level happy (yes, VFS does few S_ISFOO checks here and there, but they
all can be replaced with checks for appropriate operations being
non-NULL). Nothing prevents file system from rolling forward whatever
exotic objects it wants.
>
> Existing file API does not allow create anything but that.
> Merging reiser4 with object plugins would make it necessary to modify
> VFS layer so that files of arbitrary types could be created.
>
This is important, but it doesn't depend on whether file system has
additional layer if indirection below VFS operations. If file system
wants to support extended object types, additional parameters have to be
somehow communicated from the user level during object creation. But:
- this is necessary even if file system has no "plugins" below VFS
operations;
- this doesn't necessary means changing VFS. For example, these
parameters can be set on parent directory (this is how ACLs were
integrated into POSIX).
>
Nikita.
Re: reiser4 plugins
On Wed, Jun 22, 2005 at 06:46:50PM +0200, M. wrote: > >Is it not simpler to ask the reiserfs guys for a detailed explanation >of why and where this plugins' layer differs from using VFS for >plugins and let others comment on that ? I hope this is not FUD or something like that, but it seems to me the VFS guys are not too willing to implement Reiser4-HiFi stuff anywhere else, like the VFS, and don't want Reiser4 in, because it duplicates. Think of the chicken and the egg. I may be wrong, though. >If something cant be done using VFS this layer is needed by reiser4 >and has to be merged. But it's still possible to let Reiser4 in and take them, say, a feature at a time to the VFS. Unless it's going to be a political wankfest/pissing contest about if things like this should even be implemented, anywhere, ever :P -- mjt signature.asc Description: Digital signature
Re: reiser4 plugins
Hi, Is it not simpler to ask the reiserfs guys for a detailed explanation of why and where this plugins' layer differs from using VFS for plugins and let others comment on that ? If something cant be done using VFS this layer is needed by reiser4 and has to be merged. Michele
Re: reiser4 plugins
Markus TЖrnqvist wrote: So merge it as it is and move the stuff to the VFS as needed or deemed necessary. And enable the pseudo interface, or at least set it in menuconfig and enable by default, it needs testing too. Reiser4 has a number of great (IMO) things like file as directory, atomic operations, different kinds of stat data, fibretions, etc, etc. Some thing is not yet ready - doesn't matter. Some of this is of general interest, some is Reiser4-dedicated. New interfaces are needed to allow users to utilize that all. My point is that the things that are of general interest must not be Reiser4-only. For example, I should have a possibility to implement files-like-dir in _another_ FS using the same interfaces that Reiser4 uses. That's all I wanted to say. The other question that it may be difficult to foresee everything and it may make sense to move some things upper in future. -- Best Regards, Artem B. Bityuckiy, St.-Petersburg, Russia.
Re: reiser4 plugins
Hello
On Wed, 2005-06-22 at 18:28, Nikita Danilov wrote:
> David Masover writes:
>
> [...]
>
> >
> > Maintainability is like optimization. The maintainability of a
> > non-working program is irrelevant. You'd be right if we already had
> > plugins-in-the-VFS. We don't. The most maintainable solution for
> > plugins-in-the-FS that actually exists is Reiser4, exactly as it is now
> > - -- because it is the _only_ one that actually exists right now.
>
> But it is not so. There _are_ plugins-in-the-VFS. VFS operates on opaque
> objects (inodes, dentries, file system types) through interfaces:
> {inode,address_space,dentry,sb,etc.}_operations. Every file system
> back-end if free to implement whatever number of these interfaces. And
> the do this already: check the sources; even ext2 does this: e.g.,
> ext2_fast_symlink_inode_operations and ext2_symlink_inode_operations.
>
imho, this is something different. Ext2 decides itself how to manage a
symlink depending on length of string the symlink is to store.
Reiser4 plugins are to allow a user to define himself which operations
file is to be managed with.
> This is exactly what upper level reiser4 plugins are for.
> I guess that one of Christoph Hellwig's complaints is that reiser4
> introduces another layer of abstraction to implement something that
> already exists.
>
I do not think that it exists already.
You can have standart type of files and that is all.
Linux filesystem is not supposed to provide anything but plain
regular/directory/symlinks/sockets/block device/char device/fifo files.
Existing file API does not allow create anything but that.
Merging reiser4 with object plugins would make it necessary to modify
VFS layer so that files of arbitrary types could be created.
Re: reiser4 plugins
On Wed, Jun 22, 2005 at 07:10:58PM +0400, Artem B. Bityuckiy wrote: > >More filesystems in future may want to use these semantics. There are >cases when one can't use Reiser4 to implement them, but instead, need to >implement another file system with the same semantics. So merge it as it is and move the stuff to the VFS as needed or deemed necessary. And enable the pseudo interface, or at least set it in menuconfig and enable by default, it needs testing too. Then someone says "we can't implement this in the fs" and someone else says "we can't implement this in the vfs" and someone else says "this is a good thing which we want but you won't let us" and we stagnate again... Isn't this bickering getting a bit old? After all, it seems the code is merged in -mm, the big issues are fixed and all should be ready for more real-life testing and such? -- mjt signature.asc Description: Digital signature
Re: How to make Reiser4 plugins&namespace magic work?
Roman I Khimov wrote: Hello. Andrew Morton mentioned that "patches still contain all the reiser4-specific namespace enhancements, only it is disabled, so it is effectively dead code" and it seems this explains why I didn't see any of Reiser4 namespace magic last time I've tried to play with it. But actually I want to see it and I want to play with it - any recipe for how to revive this code? Thanks. Hello. You might want to enable pseudo interface having #define ENABLE_REISER4_PSEUDO (1) in reiser4.h, build the kernel and read this paper: http://thebsh.namesys.com/v4/pseudo.html Note, that this paper is not updated, so use "" instead of "metas". Also in order to use this interface for regular files the last ones should have an executable flag. Thanks, Edward.
Re: reiser4 plugins
Hans Reiser writes: > Andi Kleen wrote: > > > Christoph does a lot of reviewing > > > and he is notorious for making needed linux contributors go away and not > come back, and I won't say which famous person on this mailing list told > me that > > >and your child definitely > >is in serious need of that to be mergeable. I'm sure Christoph is able > >to review inpartially even when he is involved with other FS. > > > > > As impartial as a puppy on PCP > > Christoph is aggressive about things he does not take the time to > understand or ask about first. I hate that. I wish he would go away > please. He is not exactly an Ousterhout, Rob Pike, Granger, Mazieres, > Frans Kaashoek, etc., in his accomplishments, so why is he reviewing > other people's filesystems? Reviews are great, how about finding > persons who have created filesystem innovations (and thus are less > likely to reject innovations without understanding them) to do them? Well, because of his classy hair-style of course. Seriously, Linux is not managed by a committee. There is nobody to appoint Official File System Reviewers of Her Majesty. Everything here (including your credentials as a file system designer) is self-proclaimed. > > How about review by benchmark instead? [...] > I frankly think that with my > benchmarks, I should be allowed to tinker on my own. I am afraid it will sound picky, but 10 month ago you said you are planning to replace benchmarks on the namesys.com with fairer ones: http://marc.theaimsgroup.com/?l=reiserfs&m=109368686019301&w=2 Last time I checked, http://namesys.com/benchmarks.html still features only mongo runs with overwrite/modify phases off and with all operations done in readdir order (most favorable mode for reiser4). > > Hans The Mad > Nikita.
Re: reiser4 plugins
Christophe Saout wrote: The plugins that add additional VFS semantics (that are currently disable) should most definitely not be implemented only inside the filesystem. I think Hans did this because it would have been a lot more work doing this at the proper layer (which means talking to people and a lot of politics...). I would even do s/should most definitely not/must not/ More filesystems in future may want to use these semantics. There are cases when one can't use Reiser4 to implement them, but instead, need to implement another file system with the same semantics. -- Best Regards, Artem B. Bityuckiy, St.-Petersburg, Russia.
Re: reiser4 plugins
Am Dienstag, den 21.06.2005, 18:18 -0700 schrieb Andrew Morton: > > What is wrong with having an encryption plugin implemented in this > > manner? What is wrong with being able to have some files implemented > > using a compression plugin, and others in the same filesystem not. > > > > What is wrong with having one file in the FS use a write only plugin, in > > which the encrypion key is changed with every append in a forward but > > not backward computable manner, and in order to read a file you must > > either have a key that is stored on another computer or be reading what > > was written after the moment of cracking root? > > > > What is wrong with having a set of critical data files use a CRC > > checking file plugin? > > I think the concern here is that this is implemented at the wrong level. > > In Linux, a filesystem is some dumb thing which implements > address_space_operations, filesystem_operations, etc. > > Advanced features such as those which you describe are implemented on top > of the filesystem, not within it. reiser4 turns it all upside down. > > Now, some of the features which you envision are not amenable to > above-the-fs implementations. But some will be, and that's where we should > implement those. Yes, but that would be difficult, probably worse. The name "plugins" is perhaps a bit misleading. These plugins are most of the time some sort client to the reiser4 on-disk database structure. The core code is does on-disk tree handling, journalling and these things. The plugins in turn glue this core database system to the rest of the system in order to make a filesystem of it. The "file plugin" tells the database how to store files. A compression plugins is more tricky. Files should be randomly accessible and if you write in the middle of the file the compressed block might change in size. For reiser4 this is not a problem since it just tells the underlying database "give me some room for 1234 bytes and insert it in the tree instead of the other block". The reiser4 core has totally different semantics than the VFS layer and I don't see how these things could be handled elsewhere in this simple way. The reiser4 core is more some sort of library that abstracts a block device and provides some sort of database API (which is highly optimized for filesystem purposes). The actual filesystem is then another layer on top of this. You could actually implement lots of different filesystems on top of that database core. The actual layer is a bit different though. The database core itself registers with the Linux VFS and then passes the calls down to one of the plugins which then calls back into the reiser4 core to do the actual database modification. I think this was the point that Christoph was criticizing the most. Currently it looks like this: ,--. ,--. VFS ---> | | > | | | /fs/reiser4/ | | .../plugins/ | blockdev <-- | | <---> | | `--' `--' So the reiser4 code is introducing another abstraction of the Linux VFS layer instead of letting the plugins define the Linux VFS ops directly. Which would look like this: ,--. VFS --> | | ,--, | .../plugins/ | blockdev <-- | /fs/reiser4/ | <---> | | `--' `--' Which probably would be okay for most of the time except for some details (which could probably be solved otherwise). Actually the flow is not always this simple, usually the path goes back and forth multiple time between the core and the plugins. One of the features Hans is using is that there can be different kinds of files. The on-disk structure tells the core which of the plugins is responsible for the "database object" found on the disk. It could be a directory or a "stat data" (inode) or a file. The file itself could be handled by different plugins like one that stores the data directly or one that compresses it. reiser4 is different than other filesystems in that it uses a lot more abstraction levels. The database aspect and the semantic aspect of a traditional filesystems are strongly separated. To understand the code probably means a lot of work because it is a bit different. Some of the layering concerns may be right, other probably not. The plugins that add additional VFS semantics (that are currently disable) should most definitely not be implemented only inside the filesystem. I think Hans did this because it would have been a lot more work doing this at the proper layer (which means talking to people and a lot of politics...). The last time I looked at the code is a while ago, so if I'm wrong on something, please don't shoot me. The only thing I can say is that reiser4 has very stable for me (though I've gone back to re
How to make Reiser4 plugins&namespace magic work?
Hello. Andrew Morton mentioned that "patches still contain all the reiser4-specific namespace enhancements, only it is disabled, so it is effectively dead code" and it seems this explains why I didn't see any of Reiser4 namespace magic last time I've tried to play with it. But actually I want to see it and I want to play with it - any recipe for how to revive this code? Thanks. -- Roman ,---. ,--. / http://www.3os.ru/ Vhttp://www.osrc.info/ \ .o. \mailto: [EMAIL PROTECTED] ^ mailto: [EMAIL PROTECTED]/ ..o `---' `--' ooo gpg --recv-keys 0xE5E055C3 --keyserver hkp://subkeys.pgp.net signature.asc Description: Эта часть сообщения подписана цифровой подписью
Re: reiser4 plugins
On Wed, Jun 22, 2005 at 06:24:32PM +0400, Alexander Zarochentsev wrote: > Reiser plugins are for the same. Would you agree with reiser4 plugin design > if the plugins will not dispatch VFS object methods calls by themselves but > set ->foo_ops fileds instead? I guess you don't like to have the two > dispatching systems at the same level. That is exactly the point I want to make. I haven't looked at the design in detail for a long time, but schemes to allow different object to have different operation vectors is a good idea. We already have that to varying degrees in all filesystems, and making that more formal is a good thing.
Re: reiser4 plugins
David Masover writes:
[...]
>
> Maintainability is like optimization. The maintainability of a
> non-working program is irrelevant. You'd be right if we already had
> plugins-in-the-VFS. We don't. The most maintainable solution for
> plugins-in-the-FS that actually exists is Reiser4, exactly as it is now
> - -- because it is the _only_ one that actually exists right now.
But it is not so. There _are_ plugins-in-the-VFS. VFS operates on opaque
objects (inodes, dentries, file system types) through interfaces:
{inode,address_space,dentry,sb,etc.}_operations. Every file system
back-end if free to implement whatever number of these interfaces. And
the do this already: check the sources; even ext2 does this: e.g.,
ext2_fast_symlink_inode_operations and ext2_symlink_inode_operations.
This is exactly what upper level reiser4 plugins are for.
I guess that one of Christoph Hellwig's complaints is that reiser4
introduces another layer of abstraction to implement something that
already exists.
Nikita.
Re: reiser4 plugins
On Wednesday 22 June 2005 05:14, Jeff Garzik wrote: > Hans Reiser wrote: > > Christoph, > > > > Reiser4 users love the plugin concept, and all audiences which have > > listened to a presentation on plugins have been quite positive about > > it. Many users think it is the best thing about reiser4. Can you > > articulate why you are opposed to plugins in more detail? Perhaps you > > are simply not as familiar with it as the audiences I have presented > > to. Perhaps persons on our mailing list can comment. > > > > In particular, what is wrong with having a plugin id associated with > > every file, storing the pluginid on disk in permanent storage in the > > stat data, and having that plugin id define the set of methods that > > implement the vfs operations associated with a particular file, rather > > than defining VFS methods only at filesystem granularity? > > You're basically implementing another VFS layer inside of reiser4, which > is a big layering violation. Reiser4 suggests a bit more file types than VFS is aware of. I don't even think VFS should be. It is enough that VFS allows each inode/file/dentry to behave own way. IIRC VFS object's ->foo_ops is for that. Reiser plugins are for the same. Would you agree with reiser4 plugin design if the plugins will not dispatch VFS object methods calls by themselves but set ->foo_ops fileds instead? I guess you don't like to have the two dispatching systems at the same level. > This sort of feature should -not- be done at the low-level filesystem > level. > > What happens if people decide plugins are a good idea, and they want > them in ext3? We need massive surgery to extract the guts from reiser4.if > > Jeff Thanks, Alex
Re: reiser4 plugins
On Tue, 21 Jun 2005, David Masover wrote: > The point is, this was in the kernel for quite awhile, and it was so > ugly that someone would rather be fucked with a chainsaw. If something > that bad can make it in the kernel and stay for awhile because it > worked, and no one wanted to replace it I would like to think we could learn from the mistakes made in the past, instead of repeating them. Ugly code often is so ugly people don't *want* to fix it, so merging ugly code is often a big mistake. -- The Theory of Escalating Commitment: "The cost of continuing mistakes is borne by others, while the cost of admitting mistakes is borne by yourself." -- Joseph Stiglitz, Nobel Laureate in Economics
Re: reiser4 plugins
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi David > And here is the crucial point. Reiser4 is usable and useful NOW, not > after it has undergone massive surgery, and Namesys is bankrupt, and > users have given up and moved on to XFS. But the massive surgery should > happen eventually, partly to make all filesystems better (see below), > and partly to make the transition easier and more palatable for those > who don't work for Namesys. Sometimes someone comes with "I have this code NOW and if we just merge it I'll fix it up properly". It's rejected, stating "come back when you've fixed it up". We don't even have that here. We have "I have this code NOW and when it's merged I have no intention of fixing it up properly". In my eyes I'd rather take the first one than the second, there at least there's the INTENTION of fixing it up. Oh and btw, I'm not pro- or against- reiserfs in any way. I haven't tried reiserfs4 but I hear it's good so don't take this is a statement of my like or dislike of it, I'm just stating something worth thinking about. // Stefan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (MingW32) iD8DBQFCuTXZBrn2kJu9P78RAi0JAJwIp6uyAd3AL4mgSBMAH59h7CrklQCfRW+V 8ZlZqxHwnpqpHa8OURtUEuw= =OD/E -END PGP SIGNATURE-
[PATCH] [RESEND] ReiserFS _get_block_create_0 wrong behavior when I/O fails
Seems my domain is filtered , so I resend the modified version.
Related FS:
ReiserFS
Related Files:
fs/reiserfs/inode.c
Bug description:
Make a ReiserFS partition in USB storage HDD, create a test file
with
enough size.
Write a program, do: open(O_RDONLY) - read - close. After each
operation, pause for a while, such as 3s. Between open and read, unlug
the
USB wire. open returns zero-filled buffer, no error returns.
Bug analysis:
do_mpage_readpage will call FS-specific get_block to get buffer
mapped
from disk. reiserfs_get_block doesn't return non-zero when I/O failure
occurs.
reiserfs_get_block -> _get_block_create_0 ->
search_by_position_by_key
search_by_position_by_key returns IO_ERROR, but the original code just
simply
returns 0
research:
if (search_for_position_by_key (inode->i_sb, &key, &path) !=
POSITION_FOUND) {
pathrelse (&path);
if (p)
kunmap(bh_result->b_page) ;
// We do not return -ENOENT if there is a hole but page is
uptodate, because it means
// That there is some MMAPED data associated with it that is yet
to be written to disk.
if ((args & GET_BLOCK_NO_HOLE) &&
!PageUptodate(bh_result->b_page) ) {
return -ENOENT ;
}
return 0 ; <- 0 retuns for IO_ERROR
}
Way around:
test result of search_for_position_by_key
Signed-off-by: Qu Fuping<[EMAIL PROTECTED]>
Patch:
diff -uNp /tmp/linux-2.6.12-rc6/fs/reiserfs/inode.c
/tmp/linux-2.6.12-rc6.new/fs/reiserfs/inode.c
--- linux-2.6.12-rc6.old/fs/reiserfs/inode.c 2005-06-06 11:22:29.0 -0400
+++ linux-2.6.12-rc6.new/fs/reiserfs/inode.c 2005-06-17 16:12:18.0 -0400
@@ -254,6 +254,7 @@ static int _get_block_create_0 (struct i
char * p = NULL;
int chars;
int ret ;
+int result ;
int done = 0 ;
unsigned long offset ;
@@ -262,7 +263,8 @@ static int _get_block_create_0 (struct i
(loff_t)block * inode->i_sb->s_blocksize + 1, TYPE_ANY, 3);
research:
-if (search_for_position_by_key (inode->i_sb, &key, &path) != POSITION_FOUND) {
+result = search_for_position_by_key (inode->i_sb, &key, &path) ;
+if (result != POSITION_FOUND) {
pathrelse (&path);
if (p)
kunmap(bh_result->b_page) ;
@@ -270,7 +272,8 @@ research:
// That there is some MMAPED data associated with it that is yet to be written to disk.
if ((args & GET_BLOCK_NO_HOLE) && !PageUptodate(bh_result->b_page) ) {
return -ENOENT ;
- }
+ }else if(result == IO_ERROR)
+ return -EIO;
return 0 ;
}
@@ -382,7 +385,8 @@ research:
// update key to look for the next piece
set_cpu_key_k_offset (&key, cpu_key_k_offset (&key) + chars);
- if (search_for_position_by_key (inode->i_sb, &key, &path) != POSITION_FOUND)
+ result = search_for_position_by_key (inode->i_sb, &key, &path);
+ if (result != POSITION_FOUND)
// we read something from tail, even if now we got IO_ERROR
break;
bh = get_last_bh (&path);
@@ -394,6 +398,10 @@ research:
finished:
pathrelse (&path);
+
+if(result == IO_ERROR)
+ return -EIO;
+
/* this buffer has valid data, but isn't valid for io. mapping it to
* block #0 tells the rest of reiserfs it just has a tail in it
*/
become SYMANNTEC, PC GAMES, MACR0MEDIA, M1CR0S0FT FROM $20 EACH though street
Re: reiser4 plugins
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jeff Garzik wrote:
> David Masover wrote:
>
>> There's been sloppy code in the kernel before. I remember one bit in
>> particular which was commented "Fuck me gently with a chainsaw." If I
>> remember correctly, this had all of the PCI ids and the names and
>> manufacturers of the corresponding devices -- in a data structure -- in
>> C source code. It was something like one massive array definition, or
>> maybe it was a structure. I don't remember exactly, but...
>>
>> The point is, this was in the kernel for quite awhile, and it was so
>> ugly that someone would rather be fucked with a chainsaw. If something
>> that bad can make it in the kernel and stay for awhile because it
>> worked, and no one wanted to replace it -- nowdays, that database is
>> kept in userland as some nice text format -- then I vote for putting
>> Reiser4 in the kernel now, and ironing the sloppiness ("violation") out
>> later. It runs now.
>
>
> Existence of ugly code is not an excuse to add more.
Maybe not, but I'm making a point. I'm sure that, at the time, people
wanted something that ran. They wanted lspci to work. It was generally
assumed that it would be cleaned up later, and it was. Too much later,
but it happened, eventually.
I've been reading a bit of history, and the reason Linux got so popular
in the first place was the tendency to include stuff that worked and
provided a feature people wanted, even if it was ugly. The philosophy
would be: choose a good implementation over an ugly one, but choose an
ugly one over nothing at all.
> We have to maintain said ugly code for decades. Maintainability is a
> big deal when you deal with the timeframes we deal with.
Maintainability is like optimization. The maintainability of a
non-working program is irrelevant. You'd be right if we already had
plugins-in-the-VFS. We don't. The most maintainable solution for
plugins-in-the-FS that actually exists is Reiser4, exactly as it is now
- -- because it is the _only_ one that actually exists right now.
>> So, Reiser4 may eventually take over VFS and be the only Linux
>> filesystem, but if so, it will have to do it much more slowly. Take the
>> good ideas -- things like plugins -- and make them at least look like
>> incremental updates to the current VFS, and make them available to all
>> filesystems.
>
>
> This is how all Linux development is done.
>
> The code evolves over time.
>
> You have just described the path ReiserFS needs to take, in order to get
> this stuff into the kernel, in fact.
This is the path it needs to take, long term, for the sanity of
everyone. But I don't think it can get there without being included,
short term. People will stomp all over any attempts to change the VFS
as "unproven" and "unneccesary". Do you think it will be any easier to
get this stuff into the kernel that way?
Better, I think, to drop it in, as-is, and move stuff incrementally from
the FS to the VFS. That way, there's at least something intermediate
for people to use, test, and hammer/beat down, and for maintainers to
get more comfortable with the idea and the logistics of this beast in
their kernel.
>> And here is the crucial point. Reiser4 is usable and useful NOW, not
>> after it has undergone massive surgery, and Namesys is bankrupt, and
>> users have given up and moved on to XFS. But the massive surgery should
>> happen eventually, partly to make all filesystems better (see below),
>> and partly to make the transition easier and more palatable for those
>> who don't work for Namesys.
>
>
> We care about technical merit, not some random company's financial
> solvancy. Reiser4 has layering violations, and doesn't work with the
> current security layer. Those are two biggies.
Ah, so you mean to say, you care about how well something fits the
current model. That has little to do with technical merit.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iQIVAwUBQrkqoHgHNmZLgCUhAQIKixAAnTJTJJpuCLatFp8syccjNnE7WdHlO/zx
G1bWuSthCnb7uaVb8buDeAlpArzttoguKKum0NE0khz/FjKw4YUXH4AEsVYGlZaO
nBYpw0MVyypNP+hZhEuo1T826frEOb6Z40Y1WZCpYwAZCs9EQQm7TeYSMjhD17Ew
PehYwUFUmnv1S7CpYNQvuboKh/1wuUQb6R2thjuCGJVkif8Mn2U20Fhk1/HIgnIr
OHoCD8ZgwoqBDPKQ6V26dUX+ZHzQVJX1j/IgLnnitJ9E4quIHNs33lq4S99DWta6
uDS4hkHgFMRemh37sA0FUMeitFsrwNb2b2f0o/X8MpDJmwbdrdg9kxvwfHqqgaz+
Enj0rBXO8E+5a4STTk4L2LaSR2+knSEFdj53MYYq4ABL07hEbJp2cNFKh5AFXvg0
wg5WoHt4HhhOeuftIG9Twv5tHIC5qoM57ae9yZzj783G9ZnXy0xBefUmH+pWVQsp
H1IpKIR4a0l8gV1AkJa6BUyAyzDDObFzmqcZ61W15Y2relD9Ow2qzVqMxroB78uJ
O+on741BecGtohB5xdfth9rwDY6JPkDug3C6zHzxSAkGGEnWIn6O8CzcGrGqS0Ta
EmB4LGw/fZqGcEYOOErqMC6GuImv2JbjtBOx8nAxM2OhGXFoDiD9FQaDaxWw9zjj
ROODOhm0aTA=
=ivqd
-END PGP SIGNATURE-
Re: [PATCH] Fix Reiser4 Dependencies
Hans Reiser wrote: Edward Shishkin wrote: Hello, ZLIB_INFLATE/DEFLATE will be selected by special reiser4 related configuration option "Enable reiser4 compression plugins of gzip family" (REISER4_ZLIB), but since this kind of support was discussed, it is in our working repository for a while.. Anyway thanks, Edward. I am sorry, are you telling him that it works for you because you have code that is different? Did I misunderstand you? How is what is in your working repository relevant to anybody but you? Please supply a full update patch. Hans 1. The patchset reiser4-replacement-broken-out.1 for 2.6.12-rc5-mm2 is buggy and leads to compilation errors 2. To fix this one should use the fixed patchset: ftp://ftp.namesys.com/pub/reiser4-for-2.6/2.6.12-rc5-mm2/reiser4-replacement-broken-out.2.tar.gz Thanks, Edward.
Re: reiser4 plugins
Jeff Garzik wrote: >> after it has undergone massive surgery, and Namesys is bankrupt, and >> users have given up and moved on to XFS. But the massive surgery should >> happen eventually, partly to make all filesystems better (see below), >> and partly to make the transition easier and more palatable for those >> who don't work for Namesys. > > And here is the crucial point. Reiser4 is usable and useful NOW, not > > We care about technical merit, not some random company's financial > solvancy. > > > Hmm, that must be why Daniel Robbins, the creator of the distro with the technically superior Gentoo approach, is still with us, yes? If you cared about technical merit, you would discuss benchmarks, yes?
Re: -mm -> 2.6.13 merge status
Hans Reiser wrote: Jeff Garzik wrote: "Hans' team says its good stuff" is not a criteria for merging. Try benchmarking it. Maybe benchmarks mean more than our chattering. at least to the users. Still not a criteria for merging. We have to care about the code behind the benchmarks. Jeff
Re: -mm -> 2.6.13 merge status
Jeff Garzik wrote: > > > "Hans' team says its good stuff" is not a criteria for merging. > > Try benchmarking it. Maybe benchmarks mean more than our chattering. at least to the users.
Re: reiser4 plugins
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Christoph Hellwig wrote: > On Tue, Jun 21, 2005 at 11:25:24PM -0500, David Masover wrote: > >>>You're basically implementing another VFS layer inside of reiser4, which >>>is a big layering violation. >> >>There's been sloppy code in the kernel before. I remember one bit in >>particular which was commented "Fuck me gently with a chainsaw." If I >>remember correctly, this had all of the PCI ids and the names and >>manufacturers of the corresponding devices -- in a data structure -- in >>C source code. It was something like one massive array definition, or >>maybe it was a structure. I don't remember exactly, but... > > > Every device driver has a big array of corresponing device ids as an > array in C code - oh my god we're doomed .. not. I could throw the same sarcasm back at you. We must be doomed because Reiser does some stuff that VFS already does! Or am I misunderstanding the complaint? >>I agree there, too. In fact, some people have suggested that all >>"legacy" (read: non-reiser) filesystems should be implemented as Reiser4 >>plugins, effectively killing VFS.* >> >>So, Reiser4 may eventually take over VFS and be the only Linux >>filesystem, but if so, it will have to do it much more slowly. Take the >>good ideas -- things like plugins -- and make them at least look like >>incremental updates to the current VFS, and make them available to all >>filesystems. > > > And why exactly would we replace a stable, working abstraction with an unpoven > mess? How does it get proven if you won't give it a chance as a *separate* unproven mess, with a big fat EXPERIMENTAL flag, for users to play with? I know, it exists as a separate patch. But it works now, and I think the best way to "prove" it would be to package it with the kernel. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQIVAwUBQrkXY3gHNmZLgCUhAQLQUw//ZFN1KS+2wS/yDMa+/oWXVemZ690sMCLx ZlKGg82bnv2XxqMXQwuPG9V02oN/D+1bkPmZzr8rD/tm5WshxpAHroIhnp3ZVpRi lbMwULFQ8Z8fcsY3+YUag4XAUYGK+tmIeZc47FJGL0avsRa3RFJsFm+Kb6E/fi2f H4wda43rt2CJYD5GqCtMsqyxzHzPclKHq25betIcPWBOqvE5NzQbc2tFTo0n3KMb vmyZc4B34kiKhrrW/7pZCxDpiGjoxr87F19Tk8IIltM9kAuSVLXgtY/T+2DA2vJE 2N/Offr1rZh9zSq8PGkGoI+K41AaY3CkeYGjUF2eiZd4qwE624/1jUSEg685Puse 091EuIMzdndJYM0H+OsaFtvH9Rc67Hv6yR7aucNF5j8sIam37y7Fl+MToRgJK1+E 7YSpm/Ld61RaPqbJ4mqv4f0fHLTa2SpbFI8vmA1ARuiA+/YtUz9jBjLrPtMo4ppj VvNTVMmftUgRr1NlQ+MKJO4Kxt4kKQnt1OtUe2y4bjCqO7ldUvPWLKGhsY0EsS0k 9yymlBbhsjTFrY9CsyrThshyHe9ikBVSLY7i16W+KhjLF/FKaq9k93nHd4B5Shni Km9zyd0DlCUr3Y20SpBDITCWtM0CL0YQzeEW0JJTxVpHIDjh6s65XcBfrlWwEUiw j/GJZA5h+bw= =fBov -END PGP SIGNATURE-
