TongKe Xue wrote:
> A really stupid question ... why not put Reiser4 in one of the BSDs?
>
The cost to port to BSD is about $500k, and I am not possessed of a lot
of money at this time. There is also a license issue, I don't want
reiser4 to be BSD licensed, people who want proprietary additions t
Bruce, regarding "a longstanding convention of avoiding plugins in the
kernel", considering that we are the first and only ones ever to have
plugins, and considering the existence of binary kernel modules, I don't
think your characterization is accurate. Perhaps there was some
licensing controvers
On Sunday 06 August 2006 10:20, Hans Reiser wrote:
> TongKe Xue wrote:
> > A really stupid question ... why not put Reiser4 in one of the BSDs?
>
> The cost to port to BSD is about $500k, and I am not possessed of a lot
> of money at this time. There is also a license issue, I don't want
> reiser4
Bernd Schubert wrote:
An alternative might be a reiser4 fuse port. Has some advantages:
- Doesn't need to be included into the kernel.
- can be GPL
- Referring to the fuse site it also works on BSD (http://fuse4bsd.creo.hu/).
- Kills one of the major arguments on LKML - if reiser4 is included
On Sunday 06 August 2006 14:41, Lexington Luthor wrote:
> Bernd Schubert wrote:
> > An alternative might be a reiser4 fuse port. Has some advantages:
> >
> > - Doesn't need to be included into the kernel.
> >
> > - can be GPL
> >
> > - Referring to the fuse site it also works on BSD
> > (http://fus
> I know it is very easy to create ubuntu kernel packages (I have done a few)
> I might try to do one for current dapper kernel for i386. But it would have
> to wait due to time my personal constraints (projects, etc.)
Answering myself...
I tried to create a kernel package with reiser4 for ubuntu-
Hi again,
I think your characterization of plugins as something we impose on the
VFS is unfair. Plugins exist entirely internally to reiser4 --- we
to be honest I hope the force from kernel developers will not take
away any more abilities and features away from reiserfs!
If reiser4 is tied wi
(changing subject to catch Ted's attention)
Bodo Eggert schrieb am 2006-08-05:
> - I have an ext3 that can't be fixed by e2fsck (see below). fsck will fix
> some errors, trash some files and leave a fs waiting to throw the same
> error again. I'm fixing it using mkreiserfs now.
If such a bug
Bernd Schubert wrote:
Well, by having a FUSE port just more users would use reiser4, which might
increase the force to the linux distributors to include reiser4 into their
kernel versions.
I don't think reiser4 would gain many users if it is crippled by being
in userspace. All the lazy flus
On Sun, 6 Aug 2006, Matthias Andree wrote:
> (changing subject to catch Ted's attention)
> Bodo Eggert schrieb am 2006-08-05:
> > - I have an ext3 that can't be fixed by e2fsck (see below). fsck will fix
> > some errors, trash some files and leave a fs waiting to throw the same
> > error again
Lexington Luthor wrote:
Bernd Schubert wrote:
An alternative might be a reiser4 fuse port. Has some advantages:
Please please no. The kernel people will use that as an argument for
keeping it out of the kernel.
They'll use anything as an argument for keeping it out of the kernel.
This one
I'm a total idiot. Please forgive my stupidity.
From a purely technical perspective, what does VFS lack that makes
VFS-modules so much harder than Reiser-modules?
Thanks,
--TongKe
On Sun, 6 Aug 2006, David Masover wrote:
Lexington Luthor wrote:
Bernd Schubert wrote:
An alternative might b
Hi,
I was wondering on which linux supported architectures current reiser4
code is supposed to work?
This is important for my kernel-image building task :-)
--
Best regards,
Maciej
Hans Reiser wrote:
Edward Shishkin wrote:
How about we switch to ecc, which would help with bit rot not sector
loss?
Interesting aspect.
Yes, we can implement ECC as a special crypto transform that inflates
data. As I mentioned earlier, it is possible via translation of key
offsets with s
Hans:
I suspect that most of your comments are a result of mild misreadings,
or inferences that may not be inevitable.
My comments are interspersed below.
On Sun, 2006-08-06 at 03:19 -0600, Hans Reiser wrote:
> Bruce, regarding "a longstanding convention of avoiding plugins in the
> kernel", co
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 n
Pavel Machek wrote:
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
Hello,
I have had another assertion fail. This one is with 2.6.18-rc2-mm1 +
the fix in reiser4_releasepage. This was on a filesystem that had not
been unmounted cleanly. (2.6.18-rc3-mm1 crashed on me).
reiser4 panicked cowardly: reiser4[ktxnmgrd:hdb1:r(1977)]: sibling_list_remove
(fs/reiser4/tr
18 matches
Mail list logo
