On Wed 2006-08-09 02:37:45, Hans Reiser wrote:
Pavel Machek wrote:
Yes, I'm afraid redundancy/checksums kill write speed,
they kill write speed to cache, but not to disk our compression
plugin is faster than the uncompressed plugin.
Yes, you can get clever. But your
Hi!
Most users not only cannot patch a kernel, they don't know what a patch
is. It most certainly does.
obviously you can provide complete kernels, including precompiled ones.
Most distros have a yum or apt or similar tool to suck down packages,
it's trivial for users to add a
Hi!
Using guilt as an argument in a technical discussion is a flashing red
sign that says I have no technical rebuttal
Wow, that is really nervy. Let's recap this all:
* reiser4 has a 2x performance advantage over the next fastest FS
(ext3), and when compression ships in a month that
On Tue 01-08-06 11:57:10, David Masover wrote:
Horst H. von Brand wrote:
Bernd Schubert [EMAIL PROTECTED] wrote:
While filesystem speed is nice, it also would be great
if reiser4.x would be very robust against any kind of
hardware failures.
Can't have both.
Why not? I mean, other
Hi!
V3 is obsoleted by V4 in every way. V3 is old code that should be
marked as deprecated as soon as V4 has passed mass testing. V4 is far
superior in its coding style also. Having V3 in and V4 out is at this
point just stupid.
Really? Last time I checked, even V3's fsck was not too
Hi!
Can V4 survive few hours of test below?
Maybe I'm doing something wrong here, but ext2 have failed on second check
of first pass with
No, you have probably just found bug in e2fsck...
Second check...
e2fsck 1.34 (25-Jul-2003)
I have 1.38 here, so yours is too old.
OTOH if reiser4
Hi!
Second check...
e2fsck 1.34 (25-Jul-2003)
I have 1.38 here, so yours is too old.
I'll compile something new tomorrow and try to retest it.
OTOH if reiser4 survives that for 80 cycles... that's pretty good.
Actually 125 before I've got completely tired of HDD noise. :)
Hi!
Alan, this is FUD. Our V3 fsck was written after everything else was,
for lack of staffing reasons (why write an fsck before you have an FS
worth using). As a result, there was a long period where the fsck code
was unstable. It is reliable now.
People often think that our
Hi!
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 hope r4 is
better in that regard.
If you want to try
Hi!
and vfat people may decide they want cryptocompress,
I'm sure they don't, because it is mostly for Windows and assorted devices
(pendrives, digital cameras, ...) compatibility.
Actually cryptocompress for vfat *would* be nice; pen drives are
small, slow, and likely
Hi!
You won't get .tar or .tar.gz support in the VFS, for a few simple
reasons:
1. .tar and .tar.gz are complicated formats, and are therefore better
left to userland. You can get some of the same effect by using a shared
library that redefines fopen() and fread() though.
Hi!
Such support may happen for a few fs'es - people who
want this will then use those fses. Those who don't
like the ideas will use others.
(.tar, .tar.gz, ...) support in the VFS itself, and of course
transparent to any fs and any user-land application. There are many
archive FSs
Hi!
What about choosing just ... instead of metas? metas is string
that needs translation etc, while ... is nicely neutral.
cat /sound_of_silence.mp3/.../author
does not look bad, either...
... is pretty good, but I think it has been used by others, but I
really forget who. I could
Hi!
What if I do not use emacs, but vim, mcedit, gedit, or some other
editor? It doesn't seem logical to have to patch every application
that uses files.
We would have to do that in either case, so let's patch them to do it
in a nonintrusive way. And as to reading and writing
Hi!
Thats how you get yourself a non useful OS. Fix it in a library and
share it between the apps that care. Like say.. gnome-vfs2
Even KIOslave has it. They even support sftp and stuff just by using
shared files in /tmp in reality. That's a much saner interface than
doing it all in
Hi!
It is trivial to implement this by looking inside the files. I.e., the way
mc has done this for ages.
Difference is that you can't do locate or find or Search.. You
would have to open the files in an archive-supporting application
such as mc.
And would you rather that
Hi!
Application does not have to know how to handle tar/zip/etc, but it
has to make distinction between enter archives and do not enter
archives. See uservfs.sf.net.
But how do you cache the information you had to look in the archive for
in a way that other apps can use it? How do you
Hi!
However, that said, user space can trivially cache things in the
filesystem, so while this may be a convenient feature, I think you should
look at perhaps doing it in the _shell_ instead..
That cache should disappear as soon as I need disk
space. I.e. userspace should never
Hi!
| You do need extra tools anyway, placing them in the kernel is cheating
(and
| absolutely pointless, IMHO).
Repeat after me: plugins in kernel does NOT equal tools in kernel.
It's not hard to, for instance, imagine a generic plugin for archive
manipulation which talks to a
Hi!
I belive the kernel could give some assistance to make it easier to
see if a file has been modified, I remember that a few suggestions
were thrown around the last time Samba and dcache aliases were
discussed on l-k. I definitely belive that kind of infrastructure
belongs in the kernel.
Hi!
Yes, but I didn't say flame Christoph and ignore the issues ;)
Oh;-)
...
enhancements. This metafiles and file-directories stuff is actually
fairly trivial stuff.
Now I'm scared.
not as powerful. Don't
move reiser4 into vfs, use reiser4 as the vfs. Don't write
Hi!
One of the big potential uses for file-as-directory is to go inside
archive files, ELF files, .iso files and so on in a convenient way.
Arguably this belongs in userspace --- and people have put it there.
I agree that these belong in userspace, and that there's plenty* of
22 matches
Mail list logo
