Re: reiser4 plugins
Hi Hans, On 25/06/2005 12:38 a.m., Hans Reiser wrote: fsck is better in V4 than it is in V3. Users should move from V3 to V4, as V3 is obsolete. I agree on that Ted. Perhaps before moving to V4, reiser4progs-1.04 (the most recent I think) could be made to compile with gcc4/fedora core 4 system, and some of the warnings cleaned up. There are a fair lot of them - all the same warnings as below but in a heap of different files. Then of course the other slightly annoying issue that it actually aborts the compilation: [from rpmbuild -ta reiser4progs-1.0.4.tar.gz] gcc -DHAVE_CONFIG_H -I. -I. -I../../.. -I../../../include -D_REENTRANT -D_FILE_OFFSET_BITS=64 -DENABLE_SYMLINKS -DENABLE_SPECIAL -DENABLE_R5_HASH -DENABLE_FNV1_HASH -DENABLE_RUPASOV_HASH -DENABLE_TEA_HASH -DENABLE_DEG_HASH -DENABLE_LARGE_KEYS -DENABLE_SHORT_KEYS -DENABLE_DOT_O_FIBRE -DENABLE_EXT_1_FIBRE -DENABLE_EXT_3_FIBRE -DENABLE_LEXIC_FIBRE -O1 -g -O2 -g -pipe -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -m32 -march=i386 -mtune=pentium4 -fasynchronous-unwind-tables -W -Wall -Wno-unused-parameter -Wredundant-decls -MT liboid40_static_la-oid40.lo -MD -MP -MF .deps/liboid40_static_la-oid40.Tpo -c oid40.c -fPIC -DPIC -o .libs/liboid40_static_la-oid40.o oid40.c: In function 'oid40_get_state': oid40.c:12: warning: passing argument 6 of '__actual_assert' discards qualifiers from pointer target type oid40.c: In function 'oid40_get_next_oid': oid40.c:19: warning: passing argument 6 of '__actual_assert' discards qualifiers from pointer target type oid40.c: In function 'oid40_get_used_oid': oid40.c:25: warning: passing argument 6 of '__actual_assert' discards qualifiers from pointer target type oid40.c: In function 'oid40_set_state': oid40.c:32: warning: passing argument 6 of '__actual_assert' discards qualifiers from pointer target type oid40.c: In function 'oid40_set_next_oid': oid40.c:39: warning: passing argument 6 of '__actual_assert' discards qualifiers from pointer target type oid40.c: In function 'oid40_set_used_oid': oid40.c:46: warning: passing argument 6 of '__actual_assert' discards qualifiers from pointer target type oid40.c: In function 'oid40_open': oid40.c:56: warning: passing argument 6 of '__actual_assert' discards qualifiers from pointer target type oid40.c:66: warning: passing argument 6 of '__actual_assert' discards qualifiers from pointer target type oid40.c: In function 'oid40_close': oid40.c:76: warning: passing argument 6 of '__actual_assert' discards qualifiers from pointer target type oid40.c: In function 'oid40_create': oid40.c:97: warning: passing argument 6 of '__actual_assert' discards qualifiers from pointer target type oid40.c: In function 'oid40_sync': oid40.c:111: warning: passing argument 6 of '__actual_assert' discards qualifiers from pointer target type oid40.c:122: warning: passing argument 6 of '__actual_assert' discards qualifiers from pointer target type oid40.c:125: warning: passing argument 6 of '__actual_assert' discards qualifiers from pointer target type oid40.c: In function 'oid40_allocate': oid40.c:133: warning: passing argument 6 of '__actual_assert' discards qualifiers from pointer target type oid40.c: In function 'oid40_release': oid40.c:146: warning: passing argument 6 of '__actual_assert' discards qualifiers from pointer target type oid40.c: In function 'oid40_free': oid40.c:154: warning: passing argument 6 of '__actual_assert' discards qualifiers from pointer target type oid40.c: In function 'oid40_valid': oid40.c:160: warning: passing argument 6 of '__actual_assert' discards qualifiers from pointer target type oid40.c: At top level: oid40.c:204: error: static declaration of 'oid40_plug' follows non-static declaration oid40.h:33: error: previous declaration of 'oid40_plug' was here make[4]: *** [liboid40_static_la-oid40.lo] Error 1 make[4]: Leaving directory `/usr/src/redhat/BUILD/reiser4progs-1.0.4/plugin/oid/oid40' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/usr/src/redhat/BUILD/reiser4progs-1.0.4/plugin/oid' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/usr/src/redhat/BUILD/reiser4progs-1.0.4/plugin' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/src/redhat/BUILD/reiser4progs-1.0.4' make: *** [all] Error 2 error: Bad exit status from /var/tmp/rpm-tmp.23778 (%build) RPM build errors: Bad exit status from /var/tmp/rpm-tmp.23778 (%build) [EMAIL PROTECTED] tarballs]# I use ReiserFS4 on two squid cache/object partitions and it has been stable and performs well. But I haven't been in the ugly situation of having to actually compile and run an fsck on it yet... reuben
Re: reiser4 plugins
On Sun, 26 Jun 2005 00:01:39 -0400, Horst von Brand <[EMAIL PROTECTED]> said: > David Masover <[EMAIL PROTECTED]> wrote: [...] >> Also, space is not so cheap that I won't take 25% more. > It is cheap enough that I can't realistically fill the disks I have > with /usefull/ stuff. So... And since when did you become the spokesperson for all Linux users? Just because *you* can't think of a use for 25% more space doesn't mean that the rest of us don't want it. Do you really think that there isn't a significant number of people who would love to have more space? [...] > So what? Write your script to do it. Or use emacs, I'm sure it either > has now or will soon have a plugin for it... much easier to develop, > much more flexible to use, ... Oh yes. Please. Let's make everyone use emacs. Even if they want to edit an OpenOffice document or a picture. -- Hubert Chan <[EMAIL PROTECTED]> - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA Key available at wwwkeys.pgp.net. Encrypted e-mail preferred.
Re: reiser4 plugins
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Lincoln Dale wrote: > Hans Reiser wrote: > >> There has been no response to the technical email asking for what >> exactly it is that is duplicative, and what exactly it is that ought to >> be changed in how the code works, as opposed to what file the code is >> placed in, or who is considered its maintainer.There has been no >> response to the questions about whether the difference between class and >> instance makes our layer non-duplicative. >> >> Perhaps no response was possible? >> >> > Hans, > > the l-k community have asked YOU may times. any lack of response isn't > because of the kernel cabal .. its because YOU are refusing to entertain > any notion that what Reiser4 has implemented is unpalatable to the > kernel community. > > you can threaten all you want to take your code and move it to BSD. or > fork the kernel. whatever. > but if you want to get your work into the mainline kernel, you need to > provide answers to the question that keeps being asked of you - and > which you patently keep ignoring time & time again. > > in short, as per Message-ID: <[EMAIL PROTECTED]>: >posting to l-k on "why Reiser4 cannot use VFS infrastructure for >[crypto,compression,blahblah] plugins" - ideally, for each plugin. > > or again, in Message-ID: <[EMAIL PROTECTED]>: >[..] but instead just understand that this is the framework that you > have to >work in to get it into the mainline kernel. >if you don't want to go down that path, you're free to do so. >its open source, you can keep your own linux-kernel fork. >but if you want to get your code into mainline, i don't think its >so much a case of l-k folks telling you how to make your code >work under VFS. the onus is on you to say WHY your code >and plugins could never be put into VFS. > > or further back in Message-ID: <[EMAIL PROTECTED]> >you know that VFS is the mechanism in Linux. you know >(i hope..) how it works. it isn't so hard to see how many >of the Reiser4 "plug-ins" could be tied into VFS calls. >OR, if they cannot TODAY, propose how VFS _COULD_ be >made to do this. > > > NB. it doesn't matter what David thinks. this is linux-kernel, not > linux-users. Gee, thanks. Great attitude. I'm sure your users love you. By the way, Groklaw is run by a user. Ok, I'll bite. Hans put it best a moment ago: "Because our code is 90% library routines (aka plugins), eliminating the plugin layer is like eliminating main() in a user space program." We want to get a feeling of exactly which plugins you are talking about. Because if we pick the wrong ones and spend a few weeks implementing them, and come back and you think we're still too "layered" or maybe we've "bloated" VFS too much, and maybe the cycle repeats for another two years... What Hans seems to be worried about is having food and rent for two years, and the fact that in those two years, the XFS guys or the ext3 guys may duplicate enough of the "plugin" architecture that he gets no credit anymore, AND has to rewrite his stuff to work with theirs. I have to be neutral on that, as I realize that many of the linux-kernel people are sick of hearing it and honestly don't care. And to tell the truth, I'm a little sick of hearing it, and more than a little sick of the personal attacks from both sides. No, as a user, I just want a working plugin architecture to play with (I'm not *just* a user), and a working Reiser4 'cause it's fast, and I am eager to see new improvements coming out of Namesys, instead of two years spent trying to keep up with the vanilla kernel *and* adapt to some unspecified, possibly unneccessary, decree of a benevolent dictator. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQIVAwUBQr46kHgHNmZLgCUhAQKA+g//U9RiQpbaRQTBcYT4WCh+SPKJGheZCQ/S 1Xz1gI/M0phGVjfuLenpbz7CpIdfuZE670xccMXaqlYauW3D8NAkZopwLQQtuX9v MlctbWDX86Xbq0Ng3Zi6UPgKrY3kuWLP+NIjyq0geu5rnXFCgZLn2qOpZzWn1Uyf O0PNwKloBFoGeFcCs2F3HmzQ4sw2pVL645UxyatCmB/omNZIFTChkyMR4A7Ybvfc nUDtH9AMqJ/EROb3LkCQIK79I4yoDJraD64glkp/iIuADUCioVlAbyzTHuGIbFYY U3QqdOFSoCXJHC8PVSXCN1LBv4YWS2EWsYYiPiKisCHtRQi5jpZEgFdcAGbmiNaA PNIP6zfcAC8bxJ9aeH9LK+QbfzBU9LFjDIfn4TgrZdkDp+q6rHaS4EO3KWaVubn/ YDbDRd+QCDLgnzjNvQZdTXHrtotFXk+xWkKfN5e4fP5Z56EWXY1SUkv+oRC3vdJI yE0D+a8qg0XJKuFsEzhOa4Pxhu27eRCVPQ4b+s3ivmJmep3Og6v4MaG/SLTeCGMX ESHRpYUZfG81mwpI5GmkIm8E6dnZp6YmaQx9ZI9+J1B6mJ/1payL78TBIckq79Tx mKudpapkH3cZ93Br54f5C+pY/XjaHhepYZbkytl0BNb75R4T3r93s81M2q5N3ghN 3+ruvJY2Kto= =Skae -END PGP SIGNATURE-
Re: reiser4 plugins
On 6/26/05, Lincoln Dale <[EMAIL PROTECTED]> wrote: > the l-k community have asked YOU may times. any lack of response isn't > because of the kernel cabal .. its because YOU are refusing to entertain > any notion that what Reiser4 has implemented is unpalatable to the > kernel community. A lot of this is based on misconceptions, for example in recent times reiser4 is faulted for layering violations.. But it doesn't have them, it neither duplicates nor modifies the VFS. It has also been requested that reiser4 be changed to move some of it's operations above the VFS... not only would that not make sense for the currently provided functions, but merging was put off previously because of changes to the VFS now that it doesn't change the VFS we are asking hans to push it off until it does?? It's a filesysem for gods sake. Hans and his team have worked hard to minimize its impact and they are still willing to accept more guidance, even if their patience has started to run a little thin. The acceptance of reiser4 into the mainline shouldn't be any larger deal than any other filesystem, but yet it is...
Re: reiser4 plugins
Hans Reiser wrote: There has been no response to the technical email asking for what exactly it is that is duplicative, and what exactly it is that ought to be changed in how the code works, as opposed to what file the code is placed in, or who is considered its maintainer.There has been no response to the questions about whether the difference between class and instance makes our layer non-duplicative. Perhaps no response was possible? Hans, the l-k community have asked YOU may times. any lack of response isn't because of the kernel cabal .. its because YOU are refusing to entertain any notion that what Reiser4 has implemented is unpalatable to the kernel community. you can threaten all you want to take your code and move it to BSD. or fork the kernel. whatever. but if you want to get your work into the mainline kernel, you need to provide answers to the question that keeps being asked of you - and which you patently keep ignoring time & time again. in short, as per Message-ID: <[EMAIL PROTECTED]>: posting to l-k on "why Reiser4 cannot use VFS infrastructure for [crypto,compression,blahblah] plugins" - ideally, for each plugin. or again, in Message-ID: <[EMAIL PROTECTED]>: [..] but instead just understand that this is the framework that you have to work in to get it into the mainline kernel. if you don't want to go down that path, you're free to do so. its open source, you can keep your own linux-kernel fork. but if you want to get your code into mainline, i don't think its so much a case of l-k folks telling you how to make your code work under VFS. the onus is on you to say WHY your code and plugins could never be put into VFS. or further back in Message-ID: <[EMAIL PROTECTED]> you know that VFS is the mechanism in Linux. you know (i hope..) how it works. it isn't so hard to see how many of the Reiser4 "plug-ins" could be tied into VFS calls. OR, if they cannot TODAY, propose how VFS _COULD_ be made to do this. NB. it doesn't matter what David thinks. this is linux-kernel, not linux-users. cheers, lincoln.
Re: reiser4 plugins
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Horst von Brand wrote: > David Masover <[EMAIL PROTECTED]> wrote: > >>Horst von Brand wrote: >> >>>David Masover <[EMAIL PROTECTED]> wrote: >>> Horst von Brand wrote: >David Masover <[EMAIL PROTECTED]> wrote: > >>Hans Reiser wrote: >> >>>Jeff Garzik wrote: > > > [...] > > "Ain't broke" is the battle cry of stagnation. > > >>>I see it as the battle cry of those that are looking for /real/ >>>problems to solve. > > >>I'll refer you to my other rant about stagnation and oil. > > > Read it. Makes no sense, wind and solar power have their /own/ problems, > environmentally speaking. Besides, as things stand today, they are *extremely* > expnsive and hard to use, so next to useless (for now). Have you bothered to research them? The main problem is in the construction. After that... hard to use? Not really. Expensive? They pay for themselves, eventually. Plus, they get better as money goes into them. Oil *can't* get much better, but all the money goes there, instead of into alternatives. Thank you, Republicat administration... > Maybe. It's up to /you/ to convince the head kernel hackers (and me on the > way). > > >> I guess we'll only know >>if we let Reiser4 merge... > > > No. Just like devfs was "the obvious right way", it /had/ to be merged > ASAP, "wrinkles will be ironed out later". Turned out it wasn't wrinkles, > but fundamental brokenness, and it was soon abandoned by the people who > promised to maintain it forever. And now we have the flamewar about its > removal... Should it have been kept out in the beginning, before we knew we needed udev? Would we have udev at all, had devfs not been merged? But, there are some things Reiser does better and faster than ext3, > > >>>Yes, I've heard it is supposed to be faster on huge directories, and >>>doesn't run out of inodes. And it is more efficient spacewise on small >>>files. But then again, space is extremely cheap today... > > >>Speed isn't. CPU is, but not disk speed. And packing stuff more >>efficiently, without actually compressing it, will give you some of that >>speed. > > > For my current uses, ext3 is plenty fast enough. No pressing need to change. That is the problem I attempted to illustrate with the oil rant. No pressing need to change doesn't mean that something astronomically better shouldn't be adopted. Amish people live just fine. There's no pressing need for them to change. But I bet that many of them would be happier if they had a car. >>>And again, on a list around here I've seen several cries for help with >>>completely hosed filesystems, all ReiserFS. No solution has ever come >>>forth. > > >>I haven't been counting, but I've seen a number of solutions fly around >>reiserfs-list for people with reiser4 problems. > > > It was ReiserFS 3. Maybe the problems are fixed now, but as they say about > burned children... speaking for yourself? >>A lot of what people like about ext3 is its stability and fairly >>universally accepted format. A lot of what people like about XFS is its >>stability and speed, mainly with large files. A lot of what people like >>about Reiser4 (as it is today) is its speed, with large and especially >>with small files. > > > Right. And mushing it all together is way more likely to combine all /bad/ > features than to retain some of the /good/ ones. Actually, it wasn't "mushing it all together". It ended up throwing out a fair bit of it in the example I was talking about. But I really shouldn't be arguing that. It's not what people care about. >>Those are broad and somewhat uneducated statements, but I doubt most >>people care what FS they are using if the stability and performance is >>what they want. In that case, why have so much duplicated effort >>between different filesystems -- even between ISO and UDF and Reiser and >>XFS -- when most of what's really different is the on-disk format and >>the optimization? > > > Because they are different on-disk and are optimized for different uses, > perhaps? I can't use ext3 for reading my CDs, I need NTFS to access the > Windows partition here, ... As things stand. And it would be pointless to change some of those, like CDs. But then, transparent decompression as a plugin might be better. >>So, in this hypothetical situation where ext3 is a reiser4 plugin, >>suddenly all the ext3 developers are trying to improve the speed and >>reliability of reiser4, which benefits both ext3 and reiser4, instead of >>just ext3. > > > I guess that it won't ever turn out to be that simple. ext3 developers will > have to consider not screwing up XFS, etc. And I don't see any real > difference there from where we stand today... just a bigger mess: VFS with > ReiserFS with plugins for ext3, instead of VFS with ext3. No gain, much > pain. That you don't see the gain doesn't mean it doesn't exist. I don't
Re: reiser4 plugins
Think of reiser4 as being designed to be 90% library routines, and 10% program. Now, can these libraries be used by other filesystems? Why yes, some can. How many of them should be used by other filesystems? Reality: few people are going to rewrite their existing filesytems to mostly use our code. However, people writing new filesystems, if we have done our job right, will decide that our code is the easiest code base to use for implementing whatever differentiates them while avoiding reinventing what they don't seek to be better at. Detail: Regarding our allocation and balance and compress and encrypt at flush time code, unless your filesystem is also based on balanced trees it might be the least reusable code in the filesystem. It is the hardest code in the filesystem, because the algorithms we implemented were simply hard. Number one task for me, after we go in and I can stop dealing with prerequisites to inclusion, is to review the vm interaction from beginning to end one more time (and kill the emergency flush code). Good part: if you want to implement new filesystem semantics, our storage layer is more suitable for your innovating on top of than any other. Less work to code it, more functionality and flexibility, plugins are great for hacking on top of. The storage layer is very very high performance, and if semantics are your focus, using our storage layer is likely to be a good choice because it is well abstracted and works without understanding what it works on. For example, you can invent new items for the tree to balance (e.g. new directory entry formats), and all you have to do is write an item handler for the item and you don't have to touch the balancing code. In general, if a new filesystem can do some narrow aspect better than our existing library routine, it should do its aspect using its innovative new code, and where it is not trying to be better than us, it can reuse our code more easily than any alternative. Many people who would write a new filesystem from scratch, can, if they use our code base, accomplish their objectives with just writing some new plugins and contributing them to the collection. Others can define a new filesystem to consist of a particular configuration of plugins and glue that are what you get when you mount fubarfs. We would be happy to accomodate that by creating subdirectories for different flavorings of reiser4 to live in. Because our code is 90% library routines (aka plugins), eliminating the plugin layer is like eliminating main() in a user space program. Hans David Masover wrote: > Actually, I'll have to go back on this a bit. There are different kinds > of plugins, and I'm not sure exactly which people want in the VFS. This > may be because nobody's said that, though. > > Still, while plugins may not depend on Reiser, Reiser depends on plugins. > >
Re: reiser4 plugins
David Masover <[EMAIL PROTECTED]> wrote: > Horst von Brand wrote: > > David Masover <[EMAIL PROTECTED]> wrote: > >>Horst von Brand wrote: > >>>David Masover <[EMAIL PROTECTED]> wrote: > Hans Reiser wrote: > >Jeff Garzik wrote: [...] > >>"Ain't broke" is the battle cry of stagnation. > > I see it as the battle cry of those that are looking for /real/ > > problems to solve. > I'll refer you to my other rant about stagnation and oil. Read it. Makes no sense, wind and solar power have their /own/ problems, environmentally speaking. Besides, as things stand today, they are *extremely* expnsive and hard to use, so next to useless (for now). > And, listen to yourself. "Good riddance, no, I don't use DOS" but > "Ain't broke is the battle cry of those looking for real problems to solve." > You can solve real problems in DOS, Sure. But not all (or even most) problems I'd like to solve with a computer as of today. So... > it's usable, it ain't broke, there > are even some decent games (doom) and windowing systems (win3.1 and > others) for it. Sure. But that's not enough. > But Linux is better. DOS ain't broke, For me, it is. >but Linux is better. So maybe > VFS ain't broke, I think it is doing fine. > but plugins would be better. Maybe. It's up to /you/ to convince the head kernel hackers (and me on the way). >I guess we'll only know > if we let Reiser4 merge... No. Just like devfs was "the obvious right way", it /had/ to be merged ASAP, "wrinkles will be ironed out later". Turned out it wasn't wrinkles, but fundamental brokenness, and it was soon abandoned by the people who promised to maintain it forever. And now we have the flamewar about its removal... > >>But, there are some things Reiser does better and faster than ext3, > > Yes, I've heard it is supposed to be faster on huge directories, and > > doesn't run out of inodes. And it is more efficient spacewise on small > > files. But then again, space is extremely cheap today... > Speed isn't. CPU is, but not disk speed. And packing stuff more > efficiently, without actually compressing it, will give you some of that > speed. For my current uses, ext3 is plenty fast enough. No pressing need to change. > Also, space is not so cheap that I won't take 25% more. It is cheap enough that I can't realistically fill the disks I have with /usefull/ stuff. So... > > And again, on a list around here I've seen several cries for help with > > completely hosed filesystems, all ReiserFS. No solution has ever come > > forth. > I haven't been counting, but I've seen a number of solutions fly around > reiserfs-list for people with reiser4 problems. It was ReiserFS 3. Maybe the problems are fixed now, but as they say about burned children... [...] > A lot of what people like about ext3 is its stability and fairly > universally accepted format. A lot of what people like about XFS is its > stability and speed, mainly with large files. A lot of what people like > about Reiser4 (as it is today) is its speed, with large and especially > with small files. Right. And mushing it all together is way more likely to combine all /bad/ features than to retain some of the /good/ ones. > Those are broad and somewhat uneducated statements, but I doubt most > people care what FS they are using if the stability and performance is > what they want. In that case, why have so much duplicated effort > between different filesystems -- even between ISO and UDF and Reiser and > XFS -- when most of what's really different is the on-disk format and > the optimization? Because they are different on-disk and are optimized for different uses, perhaps? I can't use ext3 for reading my CDs, I need NTFS to access the Windows partition here, ... > So, in this hypothetical situation where ext3 is a reiser4 plugin, > suddenly all the ext3 developers are trying to improve the speed and > reliability of reiser4, which benefits both ext3 and reiser4, instead of > just ext3. I guess that it won't ever turn out to be that simple. ext3 developers will have to consider not screwing up XFS, etc. And I don't see any real difference there from where we stand today... just a bigger mess: VFS with ReiserFS with plugins for ext3, instead of VFS with ext3. No gain, much pain. [...] > > And that would surely break Windows compatibility (because you have to keep > > the data on what to encrypt one the filesystem itself). Besides, having > Aside from what someone else already said about this, why not just have > support for accessing, say, a .gpg file as transparently decrypted? That should, if anything, be a /user/ decision, not a /kernel/ one. Even sometimes decrypt, sometimes don't. > You > don't even need file-as-directory, just create a file called foo which > is really t
Re: reiser4 plugins
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [EMAIL PROTECTED] wrote: > On Sat, 25 Jun 2005 13:33:27 CDT, David Masover said: > >>>Now *think* for a moment - how does a hypothetical Reiser4 using ext3 format >>>gain any speed advantage with small files, when the speed advantage is based >>>on using a format other than ext3? > > >>happen in RAM. If you do a ton of work with a dataset that stays in >>RAM, Reiser probably performs as well or better than a ramdisk, because >>changes that get overwritten while still in RAM never actually touch the >>disk. > > > At that point, since the actual buffer management is being done at the VFS > level (see fs/buffer.c and friends) what you're really comparing is the speed > of journalling metadata - at which point you need to be *very* careful to No, just metadata. > specify exactly what configuration you're talking about. If you don't believe > me, investigate why mounting a filesystem with 'noatime,nodiratime' can make a > dramatic difference totally independent of the underlying filesystem, but the > actual amount of gain is dependent on format (hint - how far do the heads have > to move to record 3 atime updates against 3 random inodes on an ext2, an ext3, > and a VFAT filesystem, assuming no other disk activity), and why > ext3 has 3 different modes data=ordered/writeback/journal. I'm not saying format doesn't matter for _all_ optimizations, but there are some common ones for which it does matter. >> Reiser also doesn't fragment as quickly as ext3, and I don't >>think that has anything to do with its format. > > > Care to explain why it's not format-dependent? Reiser4 and XFS both do lazy allocation. They both avoid allocating blocks until they run out of buffer RAM. When they have to, they allocate and flush everything. This may have changed a bit -- Hans was talking about a more stack-like system, to avoid the system locking up for tens of seconds at a time while ALL ram is flushed -- but the principle is the same. That principle is that if you have a large chunk of data to allocate all at once, you are more likely to know how it should be arranged on disk. If you allocate every write(2) or every 5 seconds, how do you know if they are writing 2K or 2 gigs? You might try to pack it into 1 meg of space, then 5 megs, and so on, but you end up with quite a fragmented file. With allocate-on-flush, if you've got more like 100 megs to allocate at once, you can find space for that 100 megs. In fact, with the Reiser format, you can pack lots of tiny (much less than a block) files together to save space and speed things up. But the lack of fragmentation is not format-dependent. >>The FS that gets merged ahead of time without plugins would no longer be >>Reiser4. Go read the whitepaper, or tell me why I'm wrong, but even >>symlinks are implemented as plugins. > > > Which is another way of saying Reiser4 can't be merged in its present form. Actually, I'll have to go back on this a bit. There are different kinds of plugins, and I'm not sure exactly which people want in the VFS. This may be because nobody's said that, though. Still, while plugins may not depend on Reiser, Reiser depends on plugins. >>Actually, plugins are just as easy or easier than crypto-loop or >>dm-crypt. And why shouldn't my crypto be easy? Most users are insecure >>in all kinds of ways because of that attitude -- security is HARD, so I > > There's a vast distinction between "easy for implementors" and "easy for > users". Jaari Russo's loop-aes stuff does a wonderful job of being "easy for > users" - just say "mount", answer the passphrase, and you're good to go. The Not as easy as a plugin, though. Per-file granularity is nice. Especially on a USB key, where you're changing the files all the time. Sometimes you want just a few (encrypted) SSH/GPG keys and a bunch of (unencrypted) mpegs, and sometimes you want just a few (unencrypted) HTML files and a bunch of (encrypted) top-secret blueprints in extremely high-res JPEG/PNG format. A loop file on a keychain is only slightly better than partitions. [...] > Meanwhile, PGP was designed to be used in an environment where you could do > this: "Today's secret plans are AES256 encrypted. The key is the next key in > your one-time-pad book, XOR'ed with your 128-bit secret key - do it in your > head". > (And yes, you can easily memorize a 16-digit hex number and learn to do an XOR > with another 16-digit number, if failing to do so means you could end up > dead). > > This is inconvenient for the user, but intractable for an attacker to create a > scenario where they can just 'vi /each/decrypted/file' ;) Just as intractable the plugin way. Not to mention, setting up a ramdisk properly and decrypting to said ramdisk is a step you might forget, which might put your files on the disk unencrypted. Much more unforgivable than the heinous crime of making top-secret government work easier! >>won't do it. If secur
Re: reiser4 plugins
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hubert Chan wrote: > On Sat, 25 Jun 2005 16:31:37 -0400, [EMAIL PROTECTED] said: > > [...] > > >>Meanwhile, PGP was designed to be used in an environment where you >>could do this: "Today's secret plans are AES256 encrypted. The key is >>the next key in your one-time-pad book, XOR'ed with your 128-bit >>secret key - do it in your head". (And yes, you can easily memorize a >>16-digit hex number and learn to do an XOR with another 16-digit >>number, if failing to do so means you could end up dead). [...] > [1] I have no idea what kind of interface the crypto plugin in Reiser4 > will have. I'm assuming that there will be some commands for adding and > removing keys from the plugin. If such commands don't exist, then we > have a seriously broken system. If we do meta-files as was originally intended, the command will be a shell script could look something like this: #!/bin/bash read -sp 'passphrase: ' key echo "$key" > "$0"/.../plugins/cryptocompress/key The syntax of that echo command may change, but this is what we like about metas -- less namespace fragmentation, less random interfaces. >>Two words: "phishing e-mail". [...] > I'd rather have people encrypting all their stuff and still be > vulnerable to phishing but secure from someone stealing their computer > and fetching all their personal data, than having people not encrypt > their stuff and have all their personal data harvested when they lose > their computers and still be vulnerable to phishing. Thank you, I was just about to say that. There's a quote about this. Someone once asked Mohammed, "Should we tie up the horses or trust in Allah?" Mohammed said, "Trust in Allah. ...But, tie up the horses." > P.S. Is the custom on the linux-kernel list really to Cc: everyone and > their dog? I'm seeing a lot of long Cc: lists here... It seems to be the custom of any list to just hit "reply-to-all". That way, even if someone posted a reply after reading the archives or from a forwarded mail, or even if they unsubscribe from the list, or even if someone simply opened up their client and started a thread by mailing linux-kernel@vger.kernel.org directly, or if someone just randomly adds someone who might be interested to the CC list directly -- no matter what, someone who's posted on a topic will see replies to that post until the topic dies. Of course, this isn't true of all lists. Some lists munge headers, meaning that either "reply" or "reply-to-all" goes to the same place, meaning no automatic CC's. I don't like that, because then it's harder to take something off-list, and easier to accidently send something supposedly private to the entire list. If you take something off-list when you don't mean to, you can just re-send it, but if you put something on-list when it was supposed to be private, there isn't much you can do... Of course, there's the annoying side-effect that if you are subscribed to the list, you'll get lots of dupes, but so what? Bandwidth is cheap. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQIVAwUBQr4XAngHNmZLgCUhAQK+JRAAgg4YlZ9cb0S5hp9JzGdZHm0FeJDoKIok voT5LvqgooQpJZk3mwyagYqvP5uvY2UgFA74seMqzTHRnynCDp4orCPGgADofaFU KfjGcVUS6SuY3VgeF7WBEjFj1NHSwDp3h0LfeRocEglbFxoPGJvw3gWSnX1QDZ68 nmuSRGVSB7nb1Os6c2zsM0uXvJA43HNJ+W/UrEPOFjiRI1bOOioxzphgVwCAQH3j 8Vb2/HWmPLTCqXoOYESZ5OBQOR6iZViegh/x/Rn+O99UfiENdacoX5xwGM68SAXM CR3JjRA3JEA1iScz9I2byD2dZyb2596Q09Xh/5/5PQxK8zGm0FtWWEbOvDeF7Re7 cQiXkZB9uLQDJel+jlwatKGCPRVlx9wDJ8puIMf47QOsWhx0TY8lAxCebu4zorjz K2vQiF/ZMOYXFB5nBCvgHL7XG24FRpuaU0wWo7+0cY2o4WBhvfBO5o+93Klwa7Na ltPKRFPv6B6KBDD71quSwZ9M1YkjfR0vaPZWV9T5TFBklfRv26N1DhNmW1o2KjRI wX3yrsIbAAG9dK3Vs71oxWIw0hqmfpo4UZTZGRoi8GL+drHBNvHxzNtaeSBF4AeO fxYnQHXO1+Us3zbb/oBR4Hm3ugvsRYXMyArm1hHHFlmcXdggjz+K36IiCK7wKpfp 2gVec7JaEkY= =3Mkk -END PGP SIGNATURE-
Re: -mm -> 2.6.13 merge status
Hans Reiser schrieb: Christian Trefzer wrote: Hubert Chan schrieb: How about something of the form "nikita-955(file:line)"? Or the reverse: "file:line(nikita-955)". Would that keep everyone happy? Makes me happy. Nice, how about the others? Hey, if we need some objective and neutral mediators on lkml, I'd be glad to give my reading frenzies a meaning : ) signature.asc Description: OpenPGP digital signature
Re: -mm -> 2.6.13 merge status
Christian Trefzer wrote: > Hubert Chan schrieb: > >> How about something of the form "nikita-955(file:line)"? Or the >> reverse: "file:line(nikita-955)". Would that keep everyone happy? >> Makes me happy.
Re: -mm -> 2.6.13 merge status
Theodore Ts'o wrote:
>On Sat, Jun 25, 2005 at 12:23:41PM -0700, Hans Reiser wrote:
>
>
assert("trace_hash-89", is_hashed(foo) != 0);
>>Lots of people like corporate anonymity. Some don't. I don't. I like
>>knowing who wrote what. It helps me know who to pay how much. It helps
>>me know who to forward the bug report to. Losing your anonymity
>>exposes you, mostly for better since more communication is on balance a
>>good thing, but the fear is there for some. I don't think we can agree
>>on this, it is an issue of the soul.
>>
>>
>
>Fallacy.
>
>The assert doesn't tell you who is at fault; it tells you who placed
>the assert which triggered; it could have triggered due to bugs caused
>by anyone, including the propietary binary-only module from Nvidia
>which the user loaded into his system
>
> - Ted
>
>
>
>
If you read the thread again carefully, you will see that I already said
that it doesn't tell you who is at fault for the bug. Furthermore, I
said that the basis of the resistance of some developers to the use of
this is that they are not fully convinced that others understand that it
identifies only the assertion writer not the bug writer. As the boss of
the guys writing these assertions, I see no reason to indulge baseless
fears. When guys become experienced members of our team, they lose this
fear. Sending the bug report to the assertion writer often works nicely
as a first step, in my project, in my experience, in the cases where I
don't know anything about the likely implications of the assertion myself.
Re: -mm -> 2.6.13 merge status
Hubert Chan schrieb: How about something of the form "nikita-955(file:line)"? Or the reverse: "file:line(nikita-955)". Would that keep everyone happy? Damn, I was wondering how long it would take until someone would come up with a compromise solution ; ) Compromises everywhere will lead to nowhere, I've learned that the hard way. But this is really not a major issue, so let's not make a showstopper out of this one and the likes. For what I know about the whole inclusion discussion until now, there's been a whole lot of flamewar chickenshit so far. Considering that I have no FS developing abilities whatsoever, I'm pretty pissed at people who do know better in their field and should know better than waste their time on discussions other than constructive ones. Get the personal bullshit out of the way, everyone, please! Get in touch and work out your differences in a productive manner. If every interesting yet at first intrusive extension to the kernel causes as much kindergarten as this one, where will we end up? Stagnation sucks, yet good progress is sometimes slow-paced... Peace, everyone! Chris (hardcore, not hippie) signature.asc Description: OpenPGP digital signature
Re: reiser4 plugins
On Sat, 25 Jun 2005 16:31:37 -0400, [EMAIL PROTECTED] said:
[...]
> Meanwhile, PGP was designed to be used in an environment where you
> could do this: "Today's secret plans are AES256 encrypted. The key is
> the next key in your one-time-pad book, XOR'ed with your 128-bit
> secret key - do it in your head". (And yes, you can easily memorize a
> 16-digit hex number and learn to do an XOR with another 16-digit
> number, if failing to do so means you could end up dead).
Huh? I have no idea what this has to do with PGP vs. encryption being
handled by the filesystem/loopback/dm-crypt. What's the difference
between that scenario and "Today's secret plans are stored in the
loopback file foo.iso on an AES256 encrypted ISO. The key is ... "?
Or "Today's secret plans are stored AES256 encrypted in foo.txt. To
access it, you'll need to do {magic command to enter the key into the
filesystem} [1]. The key is ..."?
[1] I have no idea what kind of interface the crypto plugin in Reiser4
will have. I'm assuming that there will be some commands for adding and
removing keys from the plugin. If such commands don't exist, then we
have a seriously broken system.
> This is inconvenient for the user, but intractable for an attacker to
> create a scenario where they can just 'vi /each/decrypted/file' ;)
If you can memorize a 16-digit hex number and do XOR in your head, you
can learn to unmount the loopback/remove the key from the filesystem
too.
Which is definitely easier than remembering to create a temporary RAMFS,
mount it (with the right permissions!), decrypt the secret plans to that
FS, edit the plans, re-encrypt the plans, blow away the RAMFS...
>> won't do it. If security is transparent, just enter a password and
>> go, then more people would do it.
> "Just enter a password and go, then more people would do it".
> Two words: "phishing e-mail".
Social engineering works in meatspace too. Most people have locks on
their doors, even though they're easy to get around if you can pretend
to be from the electrical/gas/water company. But having locks on your
doors is better than not having locks, because it prevents other types
of attacks.
I don't care if phishing gets around encryption. It would work the same
if people didn't have their stuff encrypted. But users with encrypted
stuff are safer from other types of attacks, and no less safe from
phishing.
I'd rather have people encrypting all their stuff and still be
vulnerable to phishing but secure from someone stealing their computer
and fetching all their personal data, than having people not encrypt
their stuff and have all their personal data harvested when they lose
their computers and still be vulnerable to phishing.
P.S. Is the custom on the linux-kernel list really to Cc: everyone and
their dog? I'm seeing a lot of long Cc: lists here...
--
Hubert Chan <[EMAIL PROTECTED]> - http://www.uhoreg.ca/
PGP/GnuPG key: 1024D/124B61FA
Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA
Key available at wwwkeys.pgp.net. Encrypted e-mail preferred.
Re: -mm -> 2.6.13 merge status
On Sat, 25 Jun 2005 12:23:41 -0700, Hans Reiser <[EMAIL PROTECTED]> said:
>>> assert("trace_hash-89", is_hashed(foo) != 0);
> Lots of people like corporate anonymity. Some don't. I don't. I
> like knowing who wrote what. ...
For what it's worth (I know: not much), I like the named asserts in
Reiser4/Reiserfs. Although I haven't been bitten by any BUGs yet (maybe
I'm just lucky), whenever I see these on the mailing list, it gives the
impression that the users are interacting more directly with the
developers, and it helps us to get to know the developers better.
If people really want more standard-looking identifiers, I think Namesys
should keep the names and make a hybrid identifier, like
"nikita-123(:)"
--
Hubert Chan <[EMAIL PROTECTED]> - http://www.uhoreg.ca/
PGP/GnuPG key: 1024D/124B61FA
Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA
Key available at wwwkeys.pgp.net. Encrypted e-mail preferred.
Re: -mm -> 2.6.13 merge status
On Sat, Jun 25, 2005 at 12:23:41PM -0700, Hans Reiser wrote:
> >>
> >>assert("trace_hash-89", is_hashed(foo) != 0);
> >>
> Lots of people like corporate anonymity. Some don't. I don't. I like
> knowing who wrote what. It helps me know who to pay how much. It helps
> me know who to forward the bug report to. Losing your anonymity
> exposes you, mostly for better since more communication is on balance a
> good thing, but the fear is there for some. I don't think we can agree
> on this, it is an issue of the soul.
Fallacy.
The assert doesn't tell you who is at fault; it tells you who placed
the assert which triggered; it could have triggered due to bugs caused
by anyone, including the propietary binary-only module from Nvidia
which the user loaded into his system
- Ted
Re: reiser4 plugins
[EMAIL PROTECTED] wrote: > Hmm.. let's see.. I said Reiser isn't in because it shouldn't be > screwing with > >the VFS, and said stuff should be done separate from the Reiser4 filesystem. > > We don't touch a line of VFS code. We look like a normal fs at the interface. Shall we send in a file labeled reiservfs.c containing the plugin layer? That will really test whether the Reiser name is cursed that way, yes? There has been no response to the technical email asking for what exactly it is that is duplicative, and what exactly it is that ought to be changed in how the code works, as opposed to what file the code is placed in, or who is considered its maintainer.There has been no response to the questions about whether the difference between class and instance makes our layer non-duplicative. Perhaps no response was possible? Hans
Re: reiser4 plugins
On Sat, 25 Jun 2005 13:33:27 CDT, David Masover said: > > Now *think* for a moment - how does a hypothetical Reiser4 using ext3 format > > gain any speed advantage with small files, when the speed advantage is based > > on using a format other than ext3? > happen in RAM. If you do a ton of work with a dataset that stays in > RAM, Reiser probably performs as well or better than a ramdisk, because > changes that get overwritten while still in RAM never actually touch the > disk. At that point, since the actual buffer management is being done at the VFS level (see fs/buffer.c and friends) what you're really comparing is the speed of journalling metadata - at which point you need to be *very* careful to specify exactly what configuration you're talking about. If you don't believe me, investigate why mounting a filesystem with 'noatime,nodiratime' can make a dramatic difference totally independent of the underlying filesystem, but the actual amount of gain is dependent on format (hint - how far do the heads have to move to record 3 atime updates against 3 random inodes on an ext2, an ext3, and a VFAT filesystem, assuming no other disk activity), and why ext3 has 3 different modes data=ordered/writeback/journal. >Reiser also doesn't fragment as quickly as ext3, and I don't > think that has anything to do with its format. Care to explain why it's not format-dependent? > > b) Tell reiser4 to get its grubby little paws off the VFS if it ever intends > > to have a chance of being merged in mainline. > > You are saying Reiser isn't in because it shouldn't touch VFS. Every > single other person in this thread says Reiser isn't in because it > *should* touch VFS. Hmm.. let's see.. I said Reiser isn't in because it shouldn't be screwing with the VFS, and said stuff should be done separate from the Reiser4 filesystem. Everybody else said that to achieve all the goals that Hans wants will require changes to the VFS, and the way reiser4 gets there isn't acceptable. Seems like myself and everybody else are saying this needs to be factored into 2 pieces, a FS piece and a VFS piece, and moved forward separately. > > c) Have a *separate* project to improve the speed/reliability/function of > > the VFS layer, which is the only way that your vision of having the ext3 and > > reiser developers cooperating will ever happen. > > Why does it have to be a separate project if it is already *done* as > part of Reiser4? Or is the name Reiser just cursed that way? Because it's done *as a part of reiser4*, and not as a separately reviewed change to the VFS. > The FS that gets merged ahead of time without plugins would no longer be > Reiser4. Go read the whitepaper, or tell me why I'm wrong, but even > symlinks are implemented as plugins. Which is another way of saying Reiser4 can't be merged in its present form. > I'm not arguing that at all. But if you've got an entirely new driver, > why not do: > > Patch 1/2: Add white_whale driver, which also adds moby_foo_init to > nautical core. You don't do this because the rule is "one patch, one logical change", and "which also" implies more than one change. > Actually, plugins are just as easy or easier than crypto-loop or > dm-crypt. And why shouldn't my crypto be easy? Most users are insecure > in all kinds of ways because of that attitude -- security is HARD, so I There's a vast distinction between "easy for implementors" and "easy for users". Jaari Russo's loop-aes stuff does a wonderful job of being "easy for users" - just say "mount", answer the passphrase, and you're good to go. The underlying arguing about the crypto involved is complicated enough keep professional crypto jocks busy for years (is the watermark attack Jaari is concerned about a real threat? You tell me. ;) Meanwhile, PGP was designed to be used in an environment where you could do this: "Today's secret plans are AES256 encrypted. The key is the next key in your one-time-pad book, XOR'ed with your 128-bit secret key - do it in your head". (And yes, you can easily memorize a 16-digit hex number and learn to do an XOR with another 16-digit number, if failing to do so means you could end up dead). This is inconvenient for the user, but intractable for an attacker to create a scenario where they can just 'vi /each/decrypted/file' ;) > won't do it. If security is transparent, just enter a password and go, > then more people would do it. "Just enter a password and go, then more people would do it". Two words: "phishing e-mail". Why does phishing work at all? Because it's simple for the user, and the user isn't aware of the totally busticated underlying security model of SMTP (namely, there isn't one) and the mostly busticated security model of most browsers (the misleading concept that if an SSL site is identified by the SSL cert, that this implies the site can be trusted, and other similar misfeatures). pgpUasibn4ACr.pgp Description: PGP signature
Re: -mm -> 2.6.13 merge status
Pekka Enberg wrote:
>
>
>On Thu, 2005-06-23 at 21:32 +0200, Jens Axboe wrote:
>
>
>>That said, I don't like the reiser name-number style. If you must do
>>something like this, mark responsibility by using a named identifier
>>covering the layer in question instead.
>>
>>assert("trace_hash-89", is_hashed(foo) != 0);
>>
>>
Lots of people like corporate anonymity. Some don't. I don't. I like
knowing who wrote what. It helps me know who to pay how much. It helps
me know who to forward the bug report to. Losing your anonymity
exposes you, mostly for better since more communication is on balance a
good thing, but the fear is there for some. I don't think we can agree
on this, it is an issue of the soul.
Re: reiser4 plugins
On Wednesday 22 June 2005 05:18, Andrew Morton wrote: > Hans Reiser <[EMAIL PROTECTED]> wrote: > > 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. > It is not so already. XFS, FUSE, network fs are not of that type. Thanks, Alex.
Re: reiser4 plugins
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [EMAIL PROTECTED] wrote: > On Fri, 24 Jun 2005 23:10:35 CDT, David Masover said: > > >>But Linux is better. DOS ain't broke, but Linux is better. So maybe >>VFS ain't broke, but plugins would be better. I guess we'll only know >>if we let Reiser4 merge... > > > No, we'll only know if we merge something that does plugins at the VFS > level in a well-designed way. Which will never happen, the way you see it. (see below.) Or maybe you could see this in action if you look at the *current* code, not the hypothetical future code where reiser4 plugins are removed from the FS, which is then merged, then plugins are added to VFS, then back into reiser... (see below) >>This was about a hypothetical ext3 format as a reiser4 storage plugin. >>I'm not sure how this ties into the VFS stuff. > > > Very poorly. There's only two interpretations of "ext3 as a reiser4 plugin" > that make *any* sense. The first is that reiser4 is totally violating the VFS > layer boundary, and the second is that reiser4 is trying to be an all-singing > all-dancing wankfest. Later on, you say: You'll have to be more specific and less insulting. Actually, the way I'd like to see that is if we >>A lot of what people like about ext3 is its stability and fairly >>universally accepted format. A lot of what people like about XFS is its >>stability and speed, mainly with large files. A lot of what people like >>about Reiser4 (as it is today) is its speed, with large and especially >>with small files. > > > Now *think* for a moment - how does a hypothetical Reiser4 using ext3 format > gain any speed advantage with small files, when the speed advantage is based > on using a format other than ext3? It doesn't. It gains in other ways. Transparent cryptocompress, oddball other plugins, not to mention some speed optimizations that happen in RAM. If you do a ton of work with a dataset that stays in RAM, Reiser probably performs as well or better than a ramdisk, because changes that get overwritten while still in RAM never actually touch the disk. Reiser also doesn't fragment as quickly as ext3, and I don't think that has anything to do with its format. > The Reiser4 proponents would be well served to disavow that particular > hypothetical example - I have yet to see *anything* that does more damage > to the Reiser4 cause. It is my example. I don't speak for Namesys. I don't work at Namesys. If it does "damage", that is only in the eyes of those not paying attention. >>So, in this hypothetical situation where ext3 is a reiser4 plugin, >>suddenly all the ext3 developers are trying to improve the speed and >>reliability of reiser4, which benefits both ext3 and reiser4, instead of >>just ext3. > > > Or we can do what *should* be done, which is: > > a) Put the crack pipe down. That was unneccesary. Come back when you can debate technical reasons, not imaginary personal ones. > b) Tell reiser4 to get its grubby little paws off the VFS if it ever intends > to have a chance of being merged in mainline. You are saying Reiser isn't in because it shouldn't touch VFS. Every single other person in this thread says Reiser isn't in because it *should* touch VFS. > c) Have a *separate* project to improve the speed/reliability/function of > the VFS layer, which is the only way that your vision of having the ext3 and > reiser developers cooperating will ever happen. Why does it have to be a separate project if it is already *done* as part of Reiser4? Or is the name Reiser just cursed that way? > Yes, the VFS could probably use an overhaul. But that *will* happen like > this: > > 1) A patch is submitted and passes review to change the VFS. > 2) If appropriate, a patch for reiser4 (if it gets merged) is also submitted > (possibly by the same people) to be the first user of the new > API/functionality. The FS that gets merged ahead of time without plugins would no longer be Reiser4. Go read the whitepaper, or tell me why I'm wrong, but even symlinks are implemented as plugins. > There's a *reason* why we see patch streams that look like: > > Patch 1/3: Add moby_foo_init function to nautical core. > Patch 2/3: Modify white_whale driver to use moby_foo_init > Patch 3/3: Modify captain_ahab driver to use moby_foo_init I'm not arguing that at all. But if you've got an entirely new driver, why not do: Patch 1/2: Add white_whale driver, which also adds moby_foo_init to nautical core. Patch 2/2: Modify captain_ahab driver to use moby_foo_init >>Plus, as someone else said, it's much easier to do >>$ vim /some/encrypted/file >>than >>$ gpg --decrypt /some/encrypted/file > /some/decrypted/file >>$ vim /some/decrypted/file >>$ gpg --encrypt /some/decrypted/file > /some/encrypted/file >>$ shred /some/decrypted/file > > > You've totally failed to understand that the whole *point* of PGP is that 'vim > /some/encrypted/file' *isnt* easy to do. A better example might be the > variou
Re: -mm -> 2.6.13 merge status
Hi,
On Thu, 2005-06-23 at 21:32 +0200, Jens Axboe wrote:
> then it's impossible to know which one it is without the identical
> source at hand.
In which case, debugging is risky IMO (the source code could have
changed a lot).
On Thu, 2005-06-23 at 21:32 +0200, Jens Axboe wrote:
> That said, I don't like the reiser name-number style. If you must do
> something like this, mark responsibility by using a named identifier
> covering the layer in question instead.
>
> assert("trace_hash-89", is_hashed(foo) != 0);
A human readable message would be nicer. For example, "foo was hashed".
Pekka
Re: reiser4 plugins
El Fri, 24 Jun 2005 21:31:02 -0700, Hans Reiser <[EMAIL PROTECTED]> escribió: > What exactly is not ready Jeff? As I see it, this thread is 95% > posturing, and almost no technical reasons for not merging. These > "authorities"seem perfectly content with echoing the words of someone > who skimmed the code and shot his mouth off without understanding it, > and now these "authorities" just echo him because they like him and > assume he must be right. I'm not one of those "authorities" but I doubt reiser4 will be merged at all with that attitude.
Re: reiser4 plugins
On Fri, 24 Jun 2005 23:10:35 CDT, David Masover said: > But Linux is better. DOS ain't broke, but Linux is better. So maybe > VFS ain't broke, but plugins would be better. I guess we'll only know > if we let Reiser4 merge... No, we'll only know if we merge something that does plugins at the VFS level in a well-designed way. > This was about a hypothetical ext3 format as a reiser4 storage plugin. > I'm not sure how this ties into the VFS stuff. Very poorly. There's only two interpretations of "ext3 as a reiser4 plugin" that make *any* sense. The first is that reiser4 is totally violating the VFS layer boundary, and the second is that reiser4 is trying to be an all-singing all-dancing wankfest. Later on, you say: > A lot of what people like about ext3 is its stability and fairly > universally accepted format. A lot of what people like about XFS is its > stability and speed, mainly with large files. A lot of what people like > about Reiser4 (as it is today) is its speed, with large and especially > with small files. Now *think* for a moment - how does a hypothetical Reiser4 using ext3 format gain any speed advantage with small files, when the speed advantage is based on using a format other than ext3? As I said, either it's violating the VFS boundary, or it's busy wanking. The Reiser4 proponents would be well served to disavow that particular hypothetical example - I have yet to see *anything* that does more damage to the Reiser4 cause. > So, in this hypothetical situation where ext3 is a reiser4 plugin, > suddenly all the ext3 developers are trying to improve the speed and > reliability of reiser4, which benefits both ext3 and reiser4, instead of > just ext3. Or we can do what *should* be done, which is: a) Put the crack pipe down. b) Tell reiser4 to get its grubby little paws off the VFS if it ever intends to have a chance of being merged in mainline. c) Have a *separate* project to improve the speed/reliability/function of the VFS layer, which is the only way that your vision of having the ext3 and reiser developers cooperating will ever happen. Yes, the VFS could probably use an overhaul. But that *will* happen like this: 1) A patch is submitted and passes review to change the VFS. 2) If appropriate, a patch for reiser4 (if it gets merged) is also submitted (possibly by the same people) to be the first user of the new API/functionality. There's a *reason* why we see patch streams that look like: Patch 1/3: Add moby_foo_init function to nautical core. Patch 2/3: Modify white_whale driver to use moby_foo_init Patch 3/3: Modify captain_ahab driver to use moby_foo_init > Aside from what someone else already said about this, why not just have > support for accessing, say, a .gpg file as transparently decrypted? You > don't even need file-as-directory, just create a file called foo which > is really the decrypted version of foo.gpg. No need to change the > format, just the filesystem. I don't think this is what they mean by "Linux gives you enough rope to shoot yourself in the foot with"... > Plus, as someone else said, it's much easier to do > $ vim /some/encrypted/file > than > $ gpg --decrypt /some/encrypted/file > /some/decrypted/file > $ vim /some/decrypted/file > $ gpg --encrypt /some/decrypted/file > /some/encrypted/file > $ shred /some/decrypted/file You've totally failed to understand that the whole *point* of PGP is that 'vim /some/encrypted/file' *isnt* easy to do. A better example might be the various crypto-loop-ish variants or Microsoft's EFS, where the key management model is more tractable to this sort of automation. pgpusAjyL6l40.pgp Description: PGP signature
2.6.13 merge
Hi, Here my personal opinion of merging: I would find it very usefull the have reiserfs merged into the main kernel, but I think the kernel developers should be able to decide how they want things in. I would propose to continue discussion with kernel developers in order to determine actually how to proceed. What I would for the moment find more important would be to bring out patches as soon as a new kernel version is available. If people know that they find the new patches immediately, they will surely give reiser4 a try. I think the main problem actually is that there will be serveral weeks from the release of a new kernel until the release of the patches. For example in my case I need to upgrade to 2.6.12 due to usb problems with 2.6.11. So what are my options actually ? Well probably I will stop using reiser4 and go back to reiser3. Sure, having reiser4 immediately in the kernel would solve this problem, but so would patches coming out little time after a new kernel version is released. Here how I would proceed: 1. (most important I think) release patches only little time after the kernel is released 2. look together with kernel developers to find a solution that is pleasant for everyone Where I think 1. is much more important than 2. I know lots of people which reason for not using reiserfs is not that it is currently not in kernel, but because patches need a long time to be available after the kernel release. Also please don't get me wrong with this. I am not trying to say that reiserfs developers don't work hard, but perhaps development priorities should be changed a bit, as kernel patches being there in time is in my opinion more important than adding features or changing to be ready for inclusion in kernel. I really appreciate your hard work and give you much respect. Bye, David Arendt
Re: reiser4 plugins
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jesper Krogh wrote: > ["Followup-To:" header set to gmane.linux.kernel.] > I gmane.linux.kernel, skrev David Masover: > >>>Most desktop users today don't have backups because there is no credible >>>backup technology for 500Gb of data. They may have partial backups. Some >> >> Bandwidth is getting faster. And I just found a nice site for backups >> called streamload.com. They don't seem to support rsync, and allow only >> 100 meg downloads, but unlimited uploads. >> >> Few desktop users today really need to backup more than 50 megs of data. > > > That gives tedious manual work.. and btw, won't save you if you from > loosing stuff from when the backup was made until now. Manual? Try scripting. For me, that's a tar command involving /home, /etc, and about one or two other files, with a few excludes, like /home/shared/video. >>>things the fs can't deal with - if the disk goes boom then thats a lower >>>level concern. Also certain bits like writing to spare blocks on a >>>problem write are indeed handled drive level nowdays. >> >> Right. And putting them in the FS is unneccesary bloat if you've got >> another mechanism for dealing with it. Anyone with 500 gigs of data can >> afford to do a little RAID, or at least some burned DVDs. >> >> DVDs are cheap nowdays: >> http://www.newegg.com/Product/Product.asp?Item=N82E16817502002 > > > Again lots of manual work.. I actually have a DAT-station.. but I'm not > getting it used. People have DVD-burners, but many don't get time to do > a backup anyway. A Copy-On-Write feature in the filesystem would save > the average dataloss situation todag (for home users). Where they > accidentally deletes stuff. A lot of the people I know keep stuff on their DVDs, like movies and music, so they can carry them around. And the rest of it is the 50 megs. >> Streamload. > > > Why, when it could be quick and transparent. And Linux is used many > places where you cant let data out-of-the-house of where bandwidth > "sucks". The waste-space in my diskdrives increases everyday .. and i > fill up with a tar-ball of the system every now-and-then, but it would > definately be better suited and more effecient (save me more times) done > directly in the filesystem. Streamload is quick and transparent for me. I put files on the fileserver, it tars them up and uploads them via Streamload's perl client. >> I agree it's nice to have a more corruption-proof filesystem. >> Convenient. But not absolutely necessary. > > > Thats called raid, we have that allready. But raid won't help for and: > rm /etc/passwd, a Copy-On-Write filesystem (not-snapshot) would. Used on > a mirrored raiddisk, with enough space on the disk, it would actually > guard you from allmost anything but getting the computer stolen. > > Totally unrelated to reiser4 but a feature that would be nice to have in > "any" filesystem. Not totally unrelated. COW has been discussed. I don't remember if the low-level stuff was done, but the main complaint was a lack of a copy system call. And RAID is an argument for Reiser4's attitude that it's not the job of the FS to be corruption-proof. Still, it's far easier to avoid deleting stuff than to avoid disk failure. First priority is to get the stuff OFF the machine. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQIVAwUBQr0LxXgHNmZLgCUhAQKKBBAAiAicaEKY42s0WctOcLg/m/ciVtphQ1jY rChlThrsRCl4xAE45GgAu4P1ZdEYGwI1574W9z2j8EpbdnghX8tBHFUDSG1/K3+f 8Ud0zyMaI46k+D/IzkXS1ENYDj1PGmPAuVbM2pAa3JW0UOMzvKRsSADewxAW7OdY V9fazSYu6l7Sn64XJxpZmXs9fkElXkqaNu/2N5d6rdH8hMmLhxs8HcsbAaJ7ch87 lz2RMruQ4Keh6H6HTHHvmoYog6XakwkD0pOY0efFZolO/EZFnmIlS9VHRIyb6mls 2xKPABDh9Qq0qQxpATgmXnVI9oh9qgrp4wqQ8nTQfEnhL5fvfBTXzJgfjOJiqXUy vX4K/PP+9wzQNoqhTj4g11JBT8ilemsA4U+gbr82qSvvkOXrHkgGTQe6wgUyo6GZ R8Ui7/jmAvNw+RvfL/p0s0s3e/EimUC7ASvN64z6z77wqNH0uUfUwRmD9SL8TbTf jPdFvcd65F84T4gXphT4Dhwjs4fVjZUq3BqB+zMl3lKJP6pJfc5bqpjvqc2Rg1Yv jfpvk3gihG7YN68IgZV+9IHJG6d5P05gi/YMqu75JDkqTXe2VznOXXQp4d58PhO0 ZKJnvAfr/xKrnuwgDUjgfaHThgquyMiC95hMo4IlSEfUquKPFGY4c9k0VKQHduqc lcZOnfkvar0= =olqO -END PGP SIGNATURE-
Re: reiser4 plugins
["Followup-To:" header set to gmane.linux.kernel.] I gmane.linux.kernel, skrev David Masover: > > Most desktop users today don't have backups because there is no credible > > backup technology for 500Gb of data. They may have partial backups. Some > > Bandwidth is getting faster. And I just found a nice site for backups > called streamload.com. They don't seem to support rsync, and allow only > 100 meg downloads, but unlimited uploads. > > Few desktop users today really need to backup more than 50 megs of data. That gives tedious manual work.. and btw, won't save you if you from loosing stuff from when the backup was made until now. > > things the fs can't deal with - if the disk goes boom then thats a lower > > level concern. Also certain bits like writing to spare blocks on a > > problem write are indeed handled drive level nowdays. > > Right. And putting them in the FS is unneccesary bloat if you've got > another mechanism for dealing with it. Anyone with 500 gigs of data can > afford to do a little RAID, or at least some burned DVDs. > > DVDs are cheap nowdays: > http://www.newegg.com/Product/Product.asp?Item=N82E16817502002 Again lots of manual work.. I actually have a DAT-station.. but I'm not getting it used. People have DVD-burners, but many don't get time to do a backup anyway. A Copy-On-Write feature in the filesystem would save the average dataloss situation todag (for home users). Where they accidentally deletes stuff. > Streamload. Why, when it could be quick and transparent. And Linux is used many places where you cant let data out-of-the-house of where bandwidth "sucks". The waste-space in my diskdrives increases everyday .. and i fill up with a tar-ball of the system every now-and-then, but it would definately be better suited and more effecient (save me more times) done directly in the filesystem. > I agree it's nice to have a more corruption-proof filesystem. > Convenient. But not absolutely necessary. Thats called raid, we have that allready. But raid won't help for and: rm /etc/passwd, a Copy-On-Write filesystem (not-snapshot) would. Used on a mirrored raiddisk, with enough space on the disk, it would actually guard you from allmost anything but getting the computer stolen. Totally unrelated to reiser4 but a feature that would be nice to have in "any" filesystem. Jesper -- ./Jesper Krogh, [EMAIL PROTECTED]
