Thanks fs, Edward, can you or vs look at this?
Hans
fs wrote:
Seems my domain is filtered , so I resend the modified version.
Related FS:
ReiserFS
Related Files:
fs/reiserfs/inode.c
Bug description:
Make a ReiserFS partition in USB storage HDD, create a test file
with
enough
Hi Hans,
On 6/22/05, Hans Reiser [EMAIL PROTECTED] wrote:
I would in particular love to have you Andi Kleen do a full review of V4
if you could be that generous with your time, as I liked much of the
advice you gave us on V3.
Well, I am not Andi Kleen and this is not even in the ballpark of a
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
Pekka Enberg wrote:
Hi Hans,
On 6/22/05, Hans Reiser [EMAIL PROTECTED] wrote:
I would in particular love to have you Andi Kleen do a full review of V4
if you could be that generous with your time, as I liked much of the
advice you gave us on V3.
Well, I am not Andi Kleen and this is
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?
- Original Message -
From: Vladimir Saveliev [EMAIL PROTECTED]
To: fs [EMAIL PROTECTED]
Cc: reiserfs-list reiserfs-list@namesys.com; Hans Reiser [EMAIL
PROTECTED]; iscas-linaccident [EMAIL PROTECTED]
Sent: Thursday, June 23, 2005 5:16 PM
Subject: [iscas-linaccident 55] Re: [PATCH]
Pekka J Enberg wrote:
Hi Hans,
On Thu, 2005-06-23 at 00:42 -0700, Hans Reiser wrote:
These assertion codes are meaningless to the rest of us so please drop
them.
I think you don't appreciate the role of assertions in making code
easier to audit and debug.
I did not say you should drop
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
Hello
On Thu, 2005-06-23 at 11:42, Hans Reiser wrote:
Pekka Enberg wrote:
--- /dev/null 2003-09-23 21:59:22.0 +0400
+++ linux-2.6.11-vs/fs/reiser4/pool.c 2005-06-03 17:49:38.668204642
+0400
+/* initialise new pool */
+reiser4_internal void
On Thu, Jun 23, 2005 at 08:15:03PM +0400, Vladimir Saveliev wrote:
Pekka, would you prefer something like:
reiser4_fill_super()
{
if (init_a() == 0) {
if (init_b() == 0) {
if (init_c() == 0) {
if (init_last() == 0)
return 0;
Vladimir Saveliev wrote:
+/*
+ * Initialization stages for reiser4.
+ *
+ * These enumerate various things that have to be done during reiser4
+ * startup. Initialization code (init_reiser4()) keeps track of what stage
was
+ * reached, so that proper undo can be done if error occurs during
+
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
Pekka Enberg wrote:
--- /dev/null 2003-09-23 21:59:22.0 +0400
+++ linux-2.6.11-vs/fs/reiser4/pool.c 2005-06-03 17:49:38.668204642 +0400
+/* initialise new pool */
+reiser4_internal void
+reiser4_init_pool(reiser4_pool * pool /* pool to initialise */ ,
+ size_t obj_size /*
Jeff Mahoney [EMAIL PROTECTED] wrote:
+ assert(nikita-955, pool != NULL);
These assertion codes are meaningless to the rest of us so please drop
them.
As someone who spends time debugging reiser3 issues, I've grown
accustomed to the named assertions. They make discussing a
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
Jeff Mahoney wrote:
Pekka Enberg wrote:
--- /dev/null2003-09-23 21:59:22.0 +0400
+++ linux-2.6.11-vs/fs/reiser4/pool.c2005-06-03 17:49:38.668204642
+0400
+/* initialise new pool */
+reiser4_internal void
+reiser4_init_pool(reiser4_pool * pool /* pool to initialise */
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
On Thu, Jun 23 2005, Andrew Morton wrote:
Jeff Mahoney [EMAIL PROTECTED] wrote:
+ assert(nikita-955, pool != NULL);
These assertion codes are meaningless to the rest of us so please drop
them.
As someone who spends time debugging reiser3 issues, I've grown
accustomed to
Jeff Mahoney wrote:
All the assertions (a quick grep through the code shows something like
3800 of them) ultimately result in a reiser4_panic, which BUG()'s. Are
*all* of these assertions really worth taking the system down? I think a
reiser4_error function that can abort just that filesystem and
On 6/23/05, Olivier Galibert [EMAIL PROTECTED] wrote:
No, I think he means the traditional:
reiser4_fill_super()
{
if (init_a())
goto failed_a;
.
.
.
IMO this works very well when the initialization always completes or
fails totally in a single routine. When your init routine can
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
Hans Reiser writes:
[...]
I think the above is easier to read than the below. Macros can obscure
sometimes, and one of our weaknesses is a tendency to use macros in such
a way that it frustrates meta-. use in emacs. Nikita did however
mention that there was something that could
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
40 matches
Mail list logo
