On Sun, 26 Jun 2005 20:40:29 -0400, [EMAIL PROTECTED] said:
On Sun, 26 Jun 2005 17:35:48 CDT, David Masover said:
The kernel does not decide that. You do. And it doesn't
automatically decide that every time you create a file. You have to
use some interface to trigger the plugins.
Oh,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Kyle Moffett wrote:
On Jun 26, 2005, at 22:37:48, David Masover wrote:
$ make -C linux-2.6.12.zip/.../contents
I've yet to see how such automatic unzipping does not inherently introduce
system insecurity into _existing_ applications by
David Masover wrote:
Hans Reiser wrote:
David Masover wrote:
[EMAIL PROTECTED] wrote:
On Sun, 26 Jun 2005 14:58:07 CDT, David Masover said:
Plugins is a bad word. This user's combination of plugins is most
likely identical to other users', it's just which ones are
enabled, and
On Sun, 26 Jun 2005 21:37:48 CDT, David Masover said:
Assume we can do on-disk caching, similar to fscache/cachefs for nfs.
Now, benchmark:
$ unzip linux-2.6.12.zip make -C linux-2.6.12
versus the hypothetical
$ make -C linux-2.6.12.zip/.../contents
This is an automatic performance
On Sun, 26 Jun 2005 21:37:48 CDT, David Masover said:
Go read http://www.tux.org/lkml/#s7-7 and ponder until enlightenment
arrives.
So what? I don't intend to convince anyone based on how much
slower/faster their kernel compiles. It's meant to illustrate the
principle of the thing.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[EMAIL PROTECTED] wrote:
On Sun, 26 Jun 2005 21:37:48 CDT, David Masover said:
Go read http://www.tux.org/lkml/#s7-7 and ponder until enlightenment arrives.
So what? I don't intend to convince anyone based on how much
slower/faster their
On Sun, 26 Jun 2005 23:10:43 EDT, Hubert Chan said:
On Sun, 26 Jun 2005 20:40:29 -0400, [EMAIL PROTECTED] said:
Oh, I'm waiting for the fun the first time somebody deploys a plugin
that has similar semantics to 'chmod g+s dirname/' ;)
(You *did* notice it was set-GID of a *directory* not an
[EMAIL PROTECTED] wrote:
tarball/zipfile. Nobody ever suggested that you would actually want to.
Besides, your point was that you could not run make inside of a kernel
Umm, try it when we have it working, on a 1-4GB RAM machine it might not
be so bad. We have the compression (albeit
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[EMAIL PROTECTED] wrote:
On Sun, 26 Jun 2005 21:37:48 CDT, David Masover said:
Assume we can do on-disk caching, similar to fscache/cachefs for nfs.
Now, benchmark:
$ unzip linux-2.6.12.zip make -C linux-2.6.12
versus the hypothetical
$ make
On Mon, 27 Jun 2005 00:31:46 CDT, David Masover said:
*If* we decide that this must go both ways, *then* we either turn off
write support inside the zipfile
Oh, *that* will do wonders for command symmetry. And you just shot down
the whole 'mv foo bar' being equivalent to 'zip bar foo'
David Masover [EMAIL PROTECTED] wrote:
Hans Reiser wrote:
[...]
Reiser4 plugins are not per user, but per kernel. They are compiled
in. The model is intended to ease the development process, nothing
more. Apologies if the naming suggests more.
What do you gain by this? It is just a
On 6/27/05, Horst von Brand [EMAIL PROTECTED] wrote:
Wonderful! I carefully transparently encrypt my secret files, so
/everybody/ can read them! Now /that/ is progress!
All of this side feature argument is completely offtopic for the
inclusion of reiser4, but oh well.
In any case, the real use
David Masover [EMAIL PROTECTED] wrote:
Kyle Moffett wrote:
On Jun 26, 2005, at 22:37:48, David Masover wrote:
[...]
That just means the zip plugin has to be more carefully written than I
thought. It would have to be sandboxed and limited to prevent buffer
overruns and zip bombs.
[...]
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[EMAIL PROTECTED] wrote:
On Sun, 26 Jun 2005 23:10:43 EDT, Hubert Chan said:
On Sun, 26 Jun 2005 20:40:29 -0400, [EMAIL PROTECTED] said:
Reiser4 plugins have to be compiled into the kernel. (They're not
plugins in the sense that most people
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[EMAIL PROTECTED] wrote:
On Mon, 27 Jun 2005 00:31:46 CDT, David Masover said:
*If* we decide that this must go both ways, *then* we either turn off
write support inside the zipfile
Oh, *that* will do wonders for command symmetry. And you
Jeff Garzik wrote:
I've already listed two rather large technical reasons.
They are?
David Masover wrote:
The social traditions aren't uniform. In fact, if we're referring to
all of open source, go hang out on irc.freenode.net#gentoo for a great
community, whether or not you like the distro. If you want developers,
there's not too many RTFM's and I was coding bytecode
On 6/25/05, Hans Reiser [EMAIL PROTECTED] wrote:
I wonder if Apple is a better
social environment for developers these days than Linux? It would be
fun to work with Steve Jobs, he has such a sense of vision and a delight
in new things. He hires good people too; Dominic Giampaolo is really
[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
-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
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
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
authoritiesseem perfectly content with echoing the words of someone
who skimmed the
-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...
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
[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
-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
-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
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
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
-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:
[...]
-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
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
Nikita, I respectfully disagree with what you say about the state of our
atomicity code. It is not so far away as you describe, and probably 6
man weeks work could polish it off. You don't see the value in what I
define as useful, namely atomicity without isolation. Since you don't
see that,
Lincoln Dale wrote:
the irony of this whole thread is that history is repeating itself.
see http://www.ussg.iu.edu/hypermail/linux/kernel/0112.1/0519.html
kernel developers pushed back on you 3 years ago - in 2001 - what has
really changed?
It is exactly the same, but rather than dwell on
Hans Reiser wrote:
Lincoln Dale wrote:
the irony of this whole thread is that history is repeating itself.
see http://www.ussg.iu.edu/hypermail/linux/kernel/0112.1/0519.html
kernel developers pushed back on you 3 years ago - in 2001 - what has
really changed?
It is exactly the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hans Reiser wrote:
Nikita, I respectfully disagree with what you say about the state of our
atomicity code. It is not so far away as you describe, and probably 6
man weeks work could polish it off. You don't see the value in what I
define as
Hans Reiser wrote:
ow, if his target is reduced to whether we can eliminate a function
indirection, and whether we can review the code together and see if it
is easy to extend plugins and pluginids to other filesystems by finding
places to make it more generic and accepting of per filesystem
Al Viro wrote:
Have I missed the posting with analysis of changes in locking scheme
and update of proof of correctness? If so, please give the message ID.
_That_ had been the major showstopper for any merges, IIRC.
Ah, the prince of helpfulness has arrived.
Yes, as I remember, last time
--- Lincoln Dale [EMAIL PROTECTED] wrote:
snip
Nikita basically said as much in Message-ID:
[EMAIL PROTECTED]
earlier in this thread:
But it is not so. There _are_
plugins-in-the-VFS. VFS operates on
opaque
objects (inodes, dentries, file system types)
through interfaces:
Hans Reiser [EMAIL PROTECTED] writes:
Nikita, I respectfully disagree with what you say about the state of our
atomicity code. It is not so far away as you describe, and probably 6
man weeks work could polish it off. You don't see the value in what I
define as useful, namely atomicity
On Gwe, 2005-06-24 at 02:12, Hans Reiser wrote:
In which case the features belong in the VFS as all those with
experience and kernel contributions have been arguing.
So you fundamentally reject the prototype it in one fs and then abstract
it to others development model?
More fundamentally -
On Gwe, 2005-06-24 at 04:17, David Masover wrote:
False argument. So does the pen, so do hinges on doors. Do you still
have hinges on your doors - probably.
Indeed. Because there's nothing better -- not because I like it the
way it is.
I chose hinges carefully - there are better
On Thu, Jun 23, 2005 at 10:17:06PM -0500, David Masover wrote:
I was able to recover from bad blocks, though of course no Reiser that I
know of has had bad block relocation built in... But I got all my files
off of it, fortunately.
My experience shows that you've been very, very lucky. I
David Masover [EMAIL PROTECTED] wrote:
Alan Cox wrote:
On Iau, 2005-06-23 at 23:04, David Masover wrote:
[...]
What for? It works just fine as it stands, AFAICS.
So does DOS. Do you use DOS? I don't even use DOS to run DOS programs.
False argument. So does the pen, so do hinges on
On Fri, Jun 24, 2005 at 03:45:23PM +0100, Al Viro wrote:
On Fri, Jun 24, 2005 at 02:03:33AM -0700, Hans Reiser wrote:
Al Viro wrote:
Have I missed the posting with analysis of changes in locking scheme
and update of proof of correctness? If so, please give the message ID.
_That_
Timothy Webster [EMAIL PROTECTED] wrote:
[...]
I think it is the task of the linux community to
generalize the vfs layer and not lock out reiserfs4
until that is done.
No... the task of the Linux community is to make a better kernel.
You will have to do the work to convince it that the
On 6/24/05, Horst von Brand [EMAIL PROTECTED] wrote:
Timothy Webster [EMAIL PROTECTED] wrote:
[...]
I think it is the task of the linux community to
generalize the vfs layer and not lock out reiserfs4
until that is done.
No... the task of the Linux community is to make a better
Al Viro wrote:
On Fri, Jun 24, 2005 at 02:03:33AM -0700, Hans Reiser wrote:
Al Viro wrote:
Have I missed the posting with analysis of changes in locking scheme
and update of proof of correctness? If so, please give the message ID.
_That_ had been the major showstopper for any merges,
On Thu, 23 Jun 2005 22:41:01 -0400, Horst von Brand [EMAIL PROTECTED] said:
David Masover [EMAIL PROTECTED] wrote:
I, for one, would like to use a pendrive and have certain files be
encrypted transparently, only for use on Linux, but others be ready
to transfer to a Windows box.
And that
David Masover wrote:
I was able to recover from bad blocks, though of course no Reiser that I
know of has had bad block relocation built in...
there was a patch somewhere. Vitaly, please comment.
On Fri, 24 Jun 2005 11:13:45 MDT, Perry Kundert said:
In general, isn't it better to first include modules providing
divergent but possibly interesting functionality (such as Reiser4) as
an optional or experimental component, and then slowly re-factor
desirable functionality into higher
On 6/24/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
On Fri, 24 Jun 2005 11:13:45 MDT, Perry Kundert said:
In general, isn't it better to first include modules providing
divergent but possibly interesting functionality (such as Reiser4) as
an optional or experimental component, and
On Fri, Jun 24, 2005 at 12:21:18PM -0700, Hans Reiser wrote:
There is an area where we suffered from writing fsck last. When there
are two leaf nodes with the same key range AND the bitmap cannot be
trusted to tell us which is the valid one, we don't know which is the
most recent, and pick
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.
I also agree that Ted did a great job with fsck.ext*.
V3 was where we learned. There are performance problems in V3 that I
could only fix by writing V4. The balancing code for V3 was
On Fri, 24 Jun 2005 16:20:45 MDT, Perry Kundert said:
OK, fair enough. The file-as-directory stuff, which introduces
VFS-incompatible issues, was turned off. It requires VFS changes.
Mind you, I still think that sounds *interesting*, but it *has* to happen
at the VFS level. (And if
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[EMAIL PROTECTED] wrote:
[...]
Also, just as a personal note - talking about a reiser4 plugin that does ext3
backend storage doesn't help the cause. What you *should* be trying to sell:
To be fair, I brought that up. I don't remember if Hans
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[EMAIL PROTECTED] wrote:
[...]
Because I can envision an ext23 filesystem that is just like
reiser4, that does exactly that -- implements its variable behaviour
via a journal plugin.
So, if it did so, would you be OK with it? As long as
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Olivier Galibert wrote:
On Thu, Jun 23, 2005 at 10:17:06PM -0500, David Masover wrote:
I was able to recover from bad blocks, though of course no Reiser that I
know of has had bad block relocation built in... But I got all my files
off of it,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Alan Cox wrote:
On Gwe, 2005-06-24 at 04:17, David Masover wrote:
False argument. So does the pen, so do hinges on doors. Do you still
have hinges on your doors - probably.
Indeed. Because there's nothing better -- not because I like it the
way
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Horst von Brand wrote:
David Masover [EMAIL PROTECTED] wrote:
Alan Cox wrote:
On Iau, 2005-06-23 at 23:04, David Masover wrote:
[...]
[...]
Ain't broke is the battle cry of stagnation.
Its also the battle cry of everyone over the age of
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Horst von Brand wrote:
David Masover [EMAIL PROTECTED] wrote:
Horst von Brand wrote:
David Masover [EMAIL PROTECTED] wrote:
Hans Reiser wrote:
Jeff Garzik wrote:
[...]
You missed his point. He is saying ext3 code should migrate towards
Jeff Garzik wrote:
Then why not listen to authorities, all of whom are saying it's not
ready yet
What exactly is not ready Jeff? As I see it, this thread is 95%
posturing, and almost no technical reasons for not merging. These
authoritiesseem perfectly content with echoing the words of
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hans Reiser wrote:
[...]
David has used reiser4. Have you? Maybe you guys should try it. Maybe
you should all have less faith in your ability to skim code and
understand it instantly. Maybe you guys should actually read the
technical parts of
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
On Wed, Jun 22, 2005 at 01:33:14PM -0400, Horst von Brand 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.
It's in -mm already and it was said the big grudges are fixed.
What do you still want?
Since this did not get an answer, and since it is the technical email in
the flamefest, I thought I would resend it appropriately labeled.
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hans Reiser wrote:
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Nikita Danilov wrote:
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
David Masover wrote:
Nikita Danilov wrote:
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
On Wednesday 22 June 2005 18:29, 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
This is a very nice description, thank you Christophe. My comments are
below.
Christophe Saout wrote:
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
David Masover [EMAIL PROTECTED] wrote:
Hans Reiser wrote:
Jeff Garzik wrote:
[...]
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.
Sort of.
I think ext3 would be
Not everyone will want
to reformat at once, but as the reiser4 code matures and proves itself
(even more than it already has),
I for one have seen mainly people with wild claims that it will make their
machines much faster, and coming back
Not everyone will want
to reformat at once, but as the reiser4 code matures and proves itself
(even more than it already has),
I for one have seen mainly people with wild claims that it will make
their machines much faster, and coming back
On 6/23/05, Adrian Ulrich [EMAIL PROTECTED] wrote:
From my POV:
I've been using Reiser4 for almost everything (Rootfs / External
Harddrives) for about ~8 Months without any data loss..
Powerloss, unpluging the Disk while writing, full filesystem,
heavy use : No problems with reiser4..
Avuton Olrich wrote:
On 6/23/05, Adrian Ulrich [EMAIL PROTECTED] wrote:
From my POV:
I've been using Reiser4 for almost everything (Rootfs / External
Harddrives) for about ~8 Months without any data loss..
Powerloss, unpluging the Disk while writing, full filesystem,
heavy use : No problems
On Iau, 2005-06-23 at 06:58, Hans Reiser wrote:
Jeff Garzik wrote:
We have to maintain said ugly code for decades.
No you don't, I do.
Really. I must be mis-remembering some of the comments made about
reiserfs 3 during the 2.5 to 2.6 period.
I am entitled to get some advantage from
I think we are talking about reiser4, not reiser3..
Michele
On 6/23/05, Michael Dreher [EMAIL PROTECTED] wrote:
Not everyone will want
to reformat at once, but as the reiser4 code matures and proves itself
(even more than it already has),
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Horst von Brand wrote:
David Masover [EMAIL PROTECTED] wrote:
Hans Reiser wrote:
Jeff Garzik wrote:
[...]
You missed his point. He is saying ext3 code should migrate towards
becoming reiser4 plugins, and reiser4 should be merged now so
David Masover writes:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Nikita Danilov wrote:
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
On Iau, 2005-06-23 at 21:49, Michael Dreher wrote:
My impression: reiser3 is not 100% stable, but quite stable,
written by someone who asks for review by benchmark.
Review by uniprocessor benchmark perhaps. However Reiser4 is new code.
The original extfs on Linux was not very good either while
On Iau, 2005-06-23 at 23:04, David Masover wrote:
What for? It works just fine as it stands, AFAICS.
So does DOS. Do you use DOS? I don't even use DOS to run DOS programs.
False argument. So does the pen, so do hinges on doors. Do you still
have hinges on your doors - probably.
Ain't
One, you were using V3 not V4.
Two, this bug you mention is probably not an fs bug. rm first creates a
list of names, and then removes them.
[EMAIL PROTECTED]:~/scratch touch fufu
[EMAIL PROTECTED]:~/scratch touch fifu
[EMAIL PROTECTED]:~/scratch rm *fu fi*
rm: cannot remove `fifu': No such
David Masover wrote:
But, there are some things Reiser does better and faster than ext3, even
if you don't count file-as-directory and other toys. There's nothing
ext3 does better than Reiser, unless you count the compatibility with
random bootloaders and low-level tools.
In fairness,
Alan Cox wrote:
SMP scaling.
Reiser4 should do much better at this, as it was designed for it. I
wish we had a nice hunking multiprocessor to verify that and work
through the inevitable unintended sources of bottlenecks though.
You know how many I've had thrashed on Reiser4? Two. The
Alan Cox wrote:
I am entitled to get some advantage from being the first on the block
You were not first on the block. Linus was,
thats why it's Linux (well
not directly his fault about the name) and why he sets policy. I've
never heard Linus espousing such an idea so I wonder why you
Hans Reiser wrote:
So you fundamentally reject the prototype it in one fs and then abstract
it to others development model?
Hans,
after many years here now, one would have thought you would have got
this part of Linux: kernel development code that gets into the kernel
only does so by
Lincoln Dale wrote:
the EVMS team are a great act to follow - see
http://lwn.net/Articles/14714/ - they showed high levels of professional
conduct and made what was essentially a 'hard' but 'correct' decision in
reworking EVMS to use the same DM infrastructure as LVM2.
I just want to
-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
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
-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
-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
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
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
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,
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
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
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
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
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
801 - 900 of 1292 matches
Mail list logo
