Re: other system with datacorruption (2.425 + datalogging patches)
Another one :( -- One of my most productive days was throwing away 1000 lines of code (Ken Thompson) - PGP fingerprint: AF69 62B4 97EB F5BB 2C60 B802 568A E122 BBBE 5820 PGP Key available at http://pgp.mit.edu - reiserfsck_check.gz Description: GNU Zip compressed data reiserfsck_rebuild.gz Description: GNU Zip compressed data pgpK141jl3dqQ.pgp Description: PGP signature
Re: the 'official' point of view expressed by kernelnewbies.org regarding reiser4 inclusion
On Wed, 26 Jul 2006, Pavel Machek wrote: Hi! of the story for me. There's nothing wrong about focusing on newer code, but the old code needs to be cared for, too, to fix remaining issues such as the can only have N files with the same hash value. Requires a disk format change, in a filesystem without plugins, to fix it. Well, too bad, if reiser3 is so broken it needs on-disk-format-change, then I guess doing that change is the right thing to do... Sorry for my stupid question, but could you tell me why starting to make incompatible changes to reiserfs3 now (when reiserfs3 technology is rather old) and making reiserfs3 unstable (again), possibly for several months or even years is better than fixing big issues with reiser4 (if there are any really big left) merging it and trying to stabilize it? For end user both ways will result in mkfs so... Thanks, Grzegorz Kulewski
Re: the 'official' point of view expressed by kernelnewbies.org regarding reiser4 inclusion
On Thu, 27 Jul 2006, Grzegorz Kulewski wrote: Sorry for my stupid question, but could you tell me why starting to make incompatible changes to reiserfs3 now (when reiserfs3 technology is rather old) and making reiserfs3 unstable (again), possibly for several months or even years is better than fixing big issues with reiser4 (if there are any really big left) merging it and trying to stabilize it? For end user both ways will result in mkfs so... ext2fs and ext3fs, without plugins, added dir_index as a compatible upgrade, with an e2fsck option (that implies optional) to build indices for directories without them. ext3fs is a compatible upgrade from ext2fs, it's as simple as unmount, tune2fs -j, mount. reiserfs 3.6 could deal with 3.5 file systems, and mount -o conv with a 3.6 driver would convert a 3.5 file system to 3.6 level (ISTR it had to do with large file support and perhaps NFS exportability, but don't quote me on that). I wonder what makes the hash overflow issue so complicated (other than differing business plans, that is) that upgrading in place isn't possible. Changes introduce instability, but namesys were proud of their regression testing - so how sustainable is their internal test suite? Instead, we're told reiser4 would fix this (quite likely) and we should wait until it's ready (OK, we shouldn't be using experimental stuff for production but rather for /tmp, but the file system will take many months to mature after integration) and it will be mkfs time - so reiser4 better be mature before we go that way if there's no way back short of amrecover, restore or tar -x. Smashing out most of the Cc:s in order not to bore people. -- Matthias Andree
Re: the 'official' point of view expressed by kernelnewbies.org regarding reiser4 inclusion
Pavel Machek wrote: Hi! of the story for me. There's nothing wrong about focusing on newer code, but the old code needs to be cared for, too, to fix remaining issues such as the can only have N files with the same hash value. Requires a disk format change, in a filesystem without plugins, to fix it. Well, too bad, if reiser3 is so broken it needs on-disk-format-change, then I guess doing that change is the right thing to do... Actually, there is reiser4 brokenness lurking in Hans' statement, too: A filesystem WITH plugins must still handle the standard Linux compatibility stuff that other filesystems handle. Plugins --do not-- mean that you can just change the filesystem format willy-nilly, with zero impact. Jeff
Re: the 'official' point of view expressed by kernelnewbies.org regarding reiser4 inclusion
Jeff Garzik wrote: Pavel Machek wrote: Hi! of the story for me. There's nothing wrong about focusing on newer code, but the old code needs to be cared for, too, to fix remaining issues such as the can only have N files with the same hash value. Requires a disk format change, in a filesystem without plugins, to fix it. A filesystem WITH plugins must still handle the standard Linux compatibility stuff that other filesystems handle. Plugins --do not-- mean that you can just change the filesystem format willy-nilly, with zero impact. They --do-- mean that you can change much of the filesystem behavior without requiring massive on-disk changes or massive interface changes. After all, this is how many FUSE plugins work -- standard FS interface, usually uses another standard FS as storage, but does crazy things like compression, encryption, and other transformations in between.
Re: the 'official' point of view expressed by kernelnewbies.org regarding reiser4 inclusion
Hello David, Thursday, July 27, 2006, 3:19:15 AM, you wrote: I'm not arguing for closed source, I'm just saying that once you open, there's no going back. Many times it's a good thing, but sometimes you A sidenote. Reiser4 is open and still we don't see people writing plugins as crazy. I belive there is one group that tried to be the first outside of namesys to write a plugin but still no success. Regards, Maciej
Re: the 'official' point of view expressed by kernelnewbies.org regarding reiser4 inclusion
Maciej Sołtysiak wrote: Hello David, Thursday, July 27, 2006, 3:19:15 AM, you wrote: I'm not arguing for closed source, I'm just saying that once you open, there's no going back. Many times it's a good thing, but sometimes you A sidenote. Reiser4 is open and still we don't see people writing plugins as crazy. I belive there is one group that tried to be the first outside of namesys to write a plugin but still no success. Kernel inclusion would help a lot. Decent documentation would be better, though. Someone should look at what FUSE is doing right. Plugins fill a lot of the same niches, but with significantly better performance.
