reiserfs logging patches udpated

reiserfs logging patches udpated

[Chris Mason]

Hello everyone,

ftp.suse.com/pub/people/mason/patches/data-logging/experimental/2.6.5-rc2-mm2

Has a new set of reiserfs patches.  These should also work on 2.6.5-rc2,
but I did testing on top of -mm2 because I'm submitting part of the
patch set to Andrew.

New since the 2.6.4 code:

- add reiserfs laptop mode support
- removed patches that made it into mainline
- fixed buffer refcount problem in reiserfs-writepage-ordered-race when 
block size < page size
- fix buffer head leak in my invalidatepage func
- fix bogus warning message about locked buffers during logging

The series file has the list of the patches in the order they should be
applied.

Andrew, this subset is ready for testing -mm.  It's everything except
the xattr and ACLs, I'm still trying to convince Hans those should go
in.

reiserfs-nesting-02
reiserfs-journal-writer
reiserfs-logging
reiserfs-jh-2
reiserfs-prealloc
reiserfs-tail-jh
reiserfs-writepage-ordered-race
reiserfs-file_write_hole_sd.diff
reiserfs-laptop-mode
reiserfs-truncate-leak
reiserfs-ordered-lat
reiserfs-dirty-warning

-chris

Re: reiserfs logging patches udpated

[Christian Mayrhuber]

On Wednesday 24 March 2004 18:29, Chris Mason wrote:
> Hello everyone,
>
> ftp.suse.com/pub/people/mason/patches/data-logging/experimental/2.6.5-rc2-m
>m2
>
> Has a new set of reiserfs patches.  These should also work on 2.6.5-rc2,
> but I did testing on top of -mm2 because I'm submitting part of the
> patch set to Andrew.
>
> New since the 2.6.4 code:
>
> - add reiserfs laptop mode support
> - removed patches that made it into mainline
> - fixed buffer refcount problem in reiserfs-writepage-ordered-race when
> block size < page size
> - fix buffer head leak in my invalidatepage func
> - fix bogus warning message about locked buffers during logging
>
> The series file has the list of the patches in the order they should be
> applied.
>
> Andrew, this subset is ready for testing -mm.  It's everything except
> the xattr and ACLs, I'm still trying to convince Hans those should go
> in.

What about marking them experimental in kconfig and disable them by default?
The switches are already in Jeff's patches.
Somebody keen on rock solidness should not enable them, while others could use 
them though.

-- 
lg, Chris

Re: reiserfs logging patches udpated

[Lamont R. Peterson]

[-- Attachment #1: Type: text/plain, Size: 1237 bytes --]

On Wed, 2004-03-24 at 10:29, Chris Mason wrote:
[SNIP]
> Andrew, this subset is ready for testing -mm.  It's everything except
> the xattr and ACLs, I'm still trying to convince Hans those should go
> in.
[SNIP]

We absolutely need xattr support or else nearly everyone is going to
move to ext3.  There are those who are too scared to try to use SELinux,
FACLs or other features provided by xattrs.  But for those of us doing
"real" work, SELinux and FACLs are long overdue.

I love using ReiserFS.  I consistently see significantly better
performance and more economical use of my storage spaces with ReiserFS
over ext3, JFS or XFS in real-world use.

I will soon have all of my systems converted to using SELinux.  I do not
want to abandon ReiserFS, so I will make sure to patch my kernels as
needed.  However, most of the systems that others use (which I have set
up or whatever) are not going to see these kernels.  For most people, it
has to come with the "stock" kernel of their chosen distribution.

Please, get the xattr patches into the mainline kernel.

Thank you for all the great work.  Keep it up.
-- 
Lamont Peterson <lamont@gurulabs.com>
Senior Instructor
Guru Labs <http://www.gurulabs.com/>

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: reiserfs logging patches udpated

[Hubert Chan]

>>>>> "Chris" == Chris Mason <mason@suse.com> writes:

[...]

Chris> - add reiserfs laptop mode support

Can you explain what laptop mode is?

Thanks

-- 
Hubert Chan <hubert@uhoreg.ca> - 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: reiserfs logging patches udpated

[Chris Mason]

On Wed, 2004-03-24 at 14:49, Hubert Chan wrote:
> >>>>> "Chris" == Chris Mason <mason@suse.com> writes:
> 
> [...]
> 
> Chris> - add reiserfs laptop mode support
> 
> Can you explain what laptop mode is?

Take a look at linux/Documentation/laptop-mode.txt on any recent -mm
kernel.

The short description is that it allows you to force the filesytem into
a mode where it doesn't flush things to disk.  The risk is increased
loss of data if you crash, the gain is better battery life on laptops. 
The docs include a sample control script and other details.

The reiserfs patch is quite small, just making sure the journal honors
the flush timings requested by the rest of the kernel.

-chris

Re: reiserfs logging patches udpated

[Andrew Morton]

Chris Mason <mason@suse.com> wrote:
>
> ftp.suse.com/pub/people/mason/patches/data-logging/experimental/2.6.5-rc2-mm2
> 
> Has a new set of reiserfs patches. 

-ENODOCCO.  If people are going to test this stuff we will need setup and
usage instructions, links to userspace tool upgrades, etc, etc.

Re: reiserfs logging patches udpated

[Chris Mason]

On Wed, 2004-03-24 at 17:18, Andrew Morton wrote:
> Chris Mason <mason@suse.com> wrote:
> >
> > ftp.suse.com/pub/people/mason/patches/data-logging/experimental/2.6.5-rc2-mm2
> > 
> > Has a new set of reiserfs patches. 
> 
> -ENODOCCO.  If people are going to test this stuff we will need setup and
> usage instructions, links to userspace tool upgrades, etc, etc.

For data=ordered?  The only docs are to mount -o data=writeback if you
don't want data=ordered (which is the new default).  No tool upgrades
are required.

reiserfs needs a Documentation/filesystems/reiserfs.txt, but it needs
that in general.  I'll write one up and have the namesys guys review.

-chris

Re: reiserfs logging patches udpated

[Andrew Morton]

Chris Mason <mason@suse.com> wrote:
>
> On Wed, 2004-03-24 at 17:18, Andrew Morton wrote:
> > Chris Mason <mason@suse.com> wrote:
> > >
> > > ftp.suse.com/pub/people/mason/patches/data-logging/experimental/2.6.5-rc2-mm2
> > > 
> > > Has a new set of reiserfs patches. 
> > 
> > -ENODOCCO.  If people are going to test this stuff we will need setup and
> > usage instructions, links to userspace tool upgrades, etc, etc.
> 
> For data=ordered?  The only docs are to mount -o data=writeback if you
> don't want data=ordered (which is the new default).  No tool upgrades
> are required.

OK, thanks.  Switching the default on day one sounds radical doesn't it?

> reiserfs needs a Documentation/filesystems/reiserfs.txt, but it needs
> that in general.  I'll write one up and have the namesys guys review.

OK.  And these guys need boring old changelogs please:

reiserfs-nesting-02.patch
reiserfs-journal-writer.patch
reiserfs-logging.patch
reiserfs-jh-2.patch
reiserfs-prealloc.patch
reiserfs-tail-jh.patch
reiserfs-writepage-ordered-race.patch
reiserfs-file_write_hole_sd.diff.patch
reiserfs-laptop-mode.patch
reiserfs-truncate-leak.patch
reiserfs-ordered-lat.patch
reiserfs-dirty-warning.patch

Re: reiserfs logging patches udpated

[Chris Mason]

On Wed, 2004-03-24 at 17:35, Andrew Morton wrote:
>  
> > For data=ordered?  The only docs are to mount -o data=writeback if you
> > don't want data=ordered (which is the new default).  No tool upgrades
> > are required.
> 
> OK, thanks.  Switching the default on day one sounds radical doesn't it?
> 
It does, but the code has been in testing -suse and on the reiserfs
list.  This dooesn't mean data=ordered is perfect, but it's not quite
day one either.  I can switch the default back, but I'd rather have a
trial by fire ;-)

> > reiserfs needs a Documentation/filesystems/reiserfs.txt, but it needs
> > that in general.  I'll write one up and have the namesys guys review.
> 
> OK.  And these guys need boring old changelogs please:
> 
The top of each patch has a boring old changelog.  I can reformat them
if needed.

-chris

Re: reiserfs logging patches udpated

[Andrew Morton]

Chris Mason <mason@suse.com> wrote:
>
> On Wed, 2004-03-24 at 17:35, Andrew Morton wrote:
> >  
> > > For data=ordered?  The only docs are to mount -o data=writeback if you
> > > don't want data=ordered (which is the new default).  No tool upgrades
> > > are required.
> > 
> > OK, thanks.  Switching the default on day one sounds radical doesn't it?
> > 
> It does, but the code has been in testing -suse and on the reiserfs
> list.  This dooesn't mean data=ordered is perfect, but it's not quite
> day one either.  I can switch the default back, but I'd rather have a
> trial by fire ;-)

OK.

> > > reiserfs needs a Documentation/filesystems/reiserfs.txt, but it needs
> > > that in general.  I'll write one up and have the namesys guys review.
> > 
> > OK.  And these guys need boring old changelogs please:
> > 
> The top of each patch has a boring old changelog.  I can reformat them
> if needed.

Oh, I didn't notice that.

Anything other than one-patch-per-email with changelog in the body is a bit
of a pain.

I'll go fetch the patches again :(

Re: reiserfs logging patches udpated

[Chris Mason]

On Wed, 2004-03-24 at 17:59, Andrew Morton wrote:
> > The top of each patch has a boring old changelog.  I can reformat them
> > if needed.
> 
> Oh, I didn't notice that.
> 
> Anything other than one-patch-per-email with changelog in the body is a bit
> of a pain.
> 
> I'll go fetch the patches again :(

I can send them over private mail to you that way if you haven't already
started downloading.

-chris

Re: reiserfs logging patches udpated

[Bernd Schubert]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> It does, but the code has been in testing -suse and on the reiserfs
> list.  This dooesn't mean data=ordered is perfect, but it's not quite
> day one either.  I can switch the default back, but I'd rather have a
> trial by fire ;-)

Oh please not, just have a look at german newsgroups, there are real flamewars 
about the stability of reiserfs. Everytime someone has a disk problem and a 
reiserfs partion is affected by it, then there are more than a dozen answers 
that its the fault of reiserfs. PLEASE, don't prove them right.

The last example is less than 2 weeks old (see subject "Crash --> ReiserFS 
screwed up"), since Tim told on de.comp.os.unix.linux.misc that badblocks 
reported that his harddisk is ok, I told him to ask here. By his post here, 
one could see, that his harddisk or ide connection was not so fine as he 
previously stated, so we continued to discuss in on 
de.comp.os.unix.linux.misc and finally could solve the problem by setting a 
lower udma speed.
However, besides of the proper discussion about the ide problem, there was a 
'sub' thread with about 50 messages about the instability of reiserfs!!!

IMHO, almost all of the reported reiserfs problems are due to hardware errors, 
but some are also due to patches which are enabled by default by 
distributions like Suse or RedHat. 
Just another personal example: Before my first post on this list, I didn't 
know much about reiserfs, only that it handles system crashes better then 
ext2 and that I can have file >2GB on 2.4.x. So I went ahead and replaced 
every ext2 partition by reiserfs on the next Suse-7.0 installation. Then the 
problems arrived, since I also exported everything via nfs and since the Suse 
installer had choosen the 3.5 format without warning me about it, I run into 
serious trouble and reverted everything that was exported by nfs back to ext2 
for the next 2 years.
Even until Suse-7.3, the 3.5 format was the default from the Suse patched 
mkreiserfs, without warning the user about it.

I think -mm kernel are experimental and can include experimental stuff, but 
later in the main line everything that is experimental for the 3.6 format 
should be disabled by default. I wouldn't mind if it becomed included, but 
marked as experimental, so that one can easily wouldn't include it in a 
server kernel.


Sorry for my long (slightly off topic) message,
	Bernd
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAYiw0C8BUnAF+ydYRApYMAJ9KW83lYY9TJ7oIwiLmHwlub/cf3ACeIaSL
dPX8EuqpIH2kvMh+JPTrRGA=
=m5ez
-----END PGP SIGNATURE-----

Re: reiserfs logging patches udpated

[Chris Mason]

On Wed, 2004-03-24 at 19:47, Bernd Schubert wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> > It does, but the code has been in testing -suse and on the reiserfs
> > list.  This dooesn't mean data=ordered is perfect, but it's not quite
> > day one either.  I can switch the default back, but I'd rather have a
> > trial by fire ;-)
> 
> Oh please not, just have a look at german newsgroups, there are real flamewars 
> about the stability of reiserfs. Everytime someone has a disk problem and a 
> reiserfs partion is affected by it, then there are more than a dozen answers 
> that its the fault of reiserfs. PLEASE, don't prove them right.
> 
The code just won't get tested if it isn't turned on.  I think I've got
all the major issues fixed, and I'm sending to -mm to try and prove
that.  When we're all happy with the stability of the patches, they can
go to -linus.

But there are just as many threads about reiserfs not having
data=ordered support.  It's an important feature that has been out of
mainline for far too long.

-chris

Re: reiserfs logging patches udpated

[Dieter Nützel]

Am Donnerstag, 25. März 2004 02:00 schrieb Chris Mason:
> On Wed, 2004-03-24 at 19:47, Bernd Schubert wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > > It does, but the code has been in testing -suse and on the reiserfs
> > > list.  This dooesn't mean data=ordered is perfect, but it's not quite
> > > day one either.  I can switch the default back, but I'd rather have a
> > > trial by fire ;-)
> >
> > Oh please not, just have a look at german newsgroups, there are real
> > flamewars about the stability of reiserfs. Everytime someone has a disk
> > problem and a reiserfs partion is affected by it, then there are more
> > than a dozen answers that its the fault of reiserfs. PLEASE, don't prove
> > them right.
>
> The code just won't get tested if it isn't turned on.  I think I've got
> all the major issues fixed, and I'm sending to -mm to try and prove
> that.  When we're all happy with the stability of the patches, they can
> go to -linus.
>
> But there are just as many threads about reiserfs not having
> data=ordered support.  It's an important feature that has been out of
> mainline for far too long.

Full Ack!  --- And works for ages, even in 2.4 (SuSE).

Thanks for all _your_ effort!

-Dieter

Re: reiserfs logging patches udpated

[Bernd Schubert]

Hello Chris,

> But there are just as many threads about reiserfs not having
> data=ordered support.  It's an important feature that has been out of
> mainline for far too long.

what do you think about giving a kernel message on mounting the filesystem, 
that data logging is enabled by default now? That way people who don't know 
about it, at least would become informed on reading the log files.

Cheers,
	Bernd

Re: reiserfs logging patches udpated

[Chris Mason]

On Thu, 2004-03-25 at 13:11, Bernd Schubert wrote:
> Hello Chris,
> 
> > But there are just as many threads about reiserfs not having
> > data=ordered support.  It's an important feature that has been out of
> > mainline for far too long.
> 
> what do you think about giving a kernel message on mounting the filesystem, 
> that data logging is enabled by default now? That way people who don't know 
> about it, at least would become informed on reading the log files.

reiserfs: using ordered data mode
Reiserfs journal params: device dm-0, size 8192, journal first block 18,
max trans len 1024, max batch 900, max commit age 30, max trans age 30
reiserfs: checking transaction log (dm-0) for (dm-0)
Using r5 hash to sort names

Something like that?

-chris

Re: reiserfs logging patches udpated

[Bernd Schubert]

> reiserfs: using ordered data mode

This message doesn't tell that something has changed in recent kernel 
versions.

Actually I thought of something more eye-catching, maybe 

"Attention: data logging is enabled be default since 2.6.5-mm" 

or so. 


Bernd

Re: reiserfs logging patches udpated

[Chris Mason]

On Thu, 2004-03-25 at 13:59, Bernd Schubert wrote:
> > reiserfs: using ordered data mode
> 
> This message doesn't tell that something has changed in recent kernel 
> versions.
> 
> Actually I thought of something more eye-catching, maybe 
> 
> "Attention: data logging is enabled be default since 2.6.5-mm" 

Lets wait and see if there is any confusion in -mm.  I think the current
messages are pretty informative, but can certainly change things if
needed.

-chris

Re: reiserfs logging patches udpated

[Matthias Andree]

Chris Mason <mason@suse.com> writes:

> reiserfs: using ordered data mode
> Reiserfs journal params: device dm-0, size 8192, journal first block 18,
> max trans len 1024, max batch 900, max commit age 30, max trans age 30
> reiserfs: checking transaction log (dm-0) for (dm-0)
> Using r5 hash to sort names
>
> Something like that?

Reiserfs stuff is way too verbose already. Don't bloat it.

-- 
Matthias Andree

Encrypt your mail: my GnuPG key ID is 0x052E7D95

Re: reiserfs logging patches udpated

[Mike Fedyk]

Bernd Schubert wrote:
> However, besides of the proper discussion about the ide problem, there was a 
> 'sub' thread with about 50 messages about the instability of reiserfs!!!

I wouldn't be surprised, you get this in the debian lists also.

But, the thing is...  I wouldn't trust my data to any filesystem without 
a data=ordered mode.  I've used reiserfs on a few systems and it does 
have a speed increase, but the journaling is like ext2 -- it just 
journals what it has done, there is no ordering performed *at all* (that 
is until Suse's data=X journaling patches for reiser3).

Adding the fact that reiserfsck3 is just recently getting out of beta 
level quality (crashes, livelocks & etc during fsck and etc were common 
until the last few months)

And after having the difference of a block level journal (ext3), instead 
of a "virtual" journal(reiserfs, jfs, xfs) explained to me (check the 
ext3-users archives...) -- and how it can save your ass when there are 
hardware problems.  I was convinced and switched everything back to ext3.

The basic idea of virtual vs block journals, is that instead of using a 
few bytes to describe what you're changing in (for instance) the inode 
table (or equivalent), ext3 copies entire inode table block (usually 
1-4k depending on block size) into the journal.

Where this can save your ass is where some power or other hardware 
problem caused your drive to overwrite one of your inode tables (or 
bitmaps or...).  Well, some of your data will be corrupted, but if that 
inode table was written to relatively recently, it'll be restored from 
the journal during recovery.

Yes, I saw speed increases with reiserfs3, but I *will not* use it with 
critical systems that don't have a power backup and raid system (since 
reiserfs3 really sucks at handling bad blocks).

If I get the time, I'll help test the reiser3 patches in -mm.  Thank you 
  Chris for working on this direly needed patch, I'll feel comfortable 
with my systems running reiser3 once they're running with this patch.

Mike

Re: reiserfs logging patches udpated

[Chris Mason]

On Wed, 2004-03-24 at 22:56, Mike Fedyk wrote:

> And after having the difference of a block level journal (ext3), instead 
> of a "virtual" journal(reiserfs, jfs, xfs) explained to me (check the 
> ext3-users archives...) -- and how it can save your ass when there are 
> hardware problems.  I was convinced and switched everything back to ext3.

reiserfs does block based logging ;-)

-chris

Re: reiserfs logging patches udpated

[Mike Fedyk]

Chris Mason wrote:
> On Wed, 2004-03-24 at 22:56, Mike Fedyk wrote:
> 
> 
>>And after having the difference of a block level journal (ext3), instead 
>>of a "virtual" journal(reiserfs, jfs, xfs) explained to me (check the 
>>ext3-users archives...) -- and how it can save your ass when there are 
>>hardware problems.  I was convinced and switched everything back to ext3.
> 
> 
> reiserfs does block based logging ;-)

I stand corrected.

Thanks Chris, I feel much better about reiserfs now, especially with 
your ordered/data journaling patches.

Mike

Re: reiserfs logging patches udpated

[Chris Mason]

On Thu, 2004-03-25 at 15:41, Mike Fedyk wrote:
> Chris Mason wrote:
> > On Wed, 2004-03-24 at 22:56, Mike Fedyk wrote:
> > 
> > 
> >>And after having the difference of a block level journal (ext3), instead 
> >>of a "virtual" journal(reiserfs, jfs, xfs) explained to me (check the 
> >>ext3-users archives...) -- and how it can save your ass when there are 
> >>hardware problems.  I was convinced and switched everything back to ext3.
> > 
> > 
> > reiserfs does block based logging ;-)
> 
> I stand corrected.
> 
> Thanks Chris, I feel much better about reiserfs now, especially with 
> your ordered/data journaling patches.

One other point, the current patch set only does data=ordered.  I wanted
that fully stabilized before I enabled data=journal.

-chris

Re: reiserfs logging patches udpated

[Hans Reiser]

Chris Mason wrote:

>On Thu, 2004-03-25 at 15:41, Mike Fedyk wrote:
>  
>
>>Chris Mason wrote:
>>    
>>
>>>On Wed, 2004-03-24 at 22:56, Mike Fedyk wrote:
>>>
>>>
>>>      
>>>
>>>>And after having the difference of a block level journal (ext3), instead 
>>>>of a "virtual" journal(reiserfs, jfs, xfs) explained to me (check the 
>>>>ext3-users archives...) -- and how it can save your ass when there are 
>>>>hardware problems.  I was convinced and switched everything back to ext3.
>>>>        
>>>>
>>>reiserfs does block based logging ;-)
>>>      
>>>
>>I stand corrected.
>>
>>Thanks Chris, I feel much better about reiserfs now, especially with 
>>your ordered/data journaling patches.
>>    
>>
>
>One other point, the current patch set only does data=ordered.  I wanted
>that fully stabilized before I enabled data=journal.
>
>-chris
>
>
>
>
>  
>
what is a virtual journal?

-- 
Hans

Re: reiserfs logging patches udpated

[Mike Fedyk]

Hans Reiser wrote:
> Chris Mason wrote:
> 
>> On Thu, 2004-03-25 at 15:41, Mike Fedyk wrote:
>>  
>>
>>> Chris Mason wrote:
>>>   
>>>
>>>> On Wed, 2004-03-24 at 22:56, Mike Fedyk wrote:
>>>>
>>>>
>>>>     
>>>>
>>>>> And after having the difference of a block level journal (ext3), 
>>>>> instead of a "virtual" journal(reiserfs, jfs, xfs) explained to me 
>>>>> (check the ext3-users archives...) -- and how it can save your ass 
>>>>> when there are hardware problems.  I was convinced and switched 
>>>>> everything back to ext3.
>>>>>       
>>>>
>>>> reiserfs does block based logging ;-)
>>>>     
>>>
>>> I stand corrected.
>>>
>>> Thanks Chris, I feel much better about reiserfs now, especially with 
>>> your ordered/data journaling patches.
>>>   
>>
>>
>> One other point, the current patch set only does data=ordered.  I wanted
>> that fully stabilized before I enabled data=journal.
>>
>> -chris
>>
>>
>>
>>
>>  
>>
> what is a virtual journal?
> 

The basic idea of virtual vs block journals, is that instead of using a 
few bytes to describe what you're changing in (for instance) the inode 
table (or equivalent), ext3 (and reiser3 thanks to info from Chris 
Mason) copies entire inode table block (usually 1-4k depending on block 
size) into the journal.

Re: reiserfs logging patches udpated

[Nikita Danilov]

Mike Fedyk writes:

[...]

 > 
 > The basic idea of virtual vs block journals, is that instead of using a 
 > few bytes to describe what you're changing in (for instance) the inode 
 > table (or equivalent), ext3 (and reiser3 thanks to info from Chris 
 > Mason) copies entire inode table block (usually 1-4k depending on block 
 > size) into the journal.

Unless I am missing something this is called "logical logging" (as
opposed to the "physical logging") in the data-base literature.

Nikita.

Re: reiserfs logging patches udpated

[Mike Fedyk]

Nikita Danilov wrote:
> Mike Fedyk writes:
> 
> [...]
> 
>  > 
>  > The basic idea of virtual vs block journals, is that instead of using a 
>  > few bytes to describe what you're changing in (for instance) the inode 
>  > table (or equivalent), ext3 (and reiser3 thanks to info from Chris 
>  > Mason) copies entire inode table block (usually 1-4k depending on block 
>  > size) into the journal.
> 
> Unless I am missing something this is called "logical logging" (as
> opposed to the "physical logging") in the data-base literature.

Yes, thanks for pointing that out.  I had forgotten the correct term 
(and mentioned that in my first message about that at the time). 
"Virtual" was the best approximation I could think of when I was writing 
that up.

Mike

Re: reiserfs logging patches udpated

[Dieter Nützel]

Am Donnerstag, 25. März 2004 04:56 schrieb Mike Fedyk:
> Bernd Schubert wrote:
> > However, besides of the proper discussion about the ide problem, there
> > was a 'sub' thread with about 50 messages about the instability of
> > reiserfs!!!
>
> I wouldn't be surprised, you get this in the debian lists also.

> Adding the fact that reiserfsck3 is just recently getting out of beta
> level quality (crashes, livelocks & etc during fsck and etc were common
> until the last few months)

What? - Nothing, here (for years) even on LVM on-top of RAID.

-Dieter

Re: reiserfs logging patches udpated

[Matthias Andree]

Bernd Schubert <bernd-schubert@web.de> writes:

>> It does, but the code has been in testing -suse and on the reiserfs
>> list.  This dooesn't mean data=ordered is perfect, but it's not quite
>> day one either.  I can switch the default back, but I'd rather have a
>> trial by fire ;-)
>
> Oh please not, just have a look at german newsgroups, there are real flamewars 
> about the stability of reiserfs. Everytime someone has a disk problem and a 
> reiserfs partion is affected by it, then there are more than a dozen answers 
> that its the fault of reiserfs. PLEASE, don't prove them right.

Sure, distros ship outdated reiserfsck and kernels, that can't fix half
of the real-life bugs and users don't switch off their write caches but
may switch off their machines - how's that supposed to work out?

> reported that his harddisk is ok, I told him to ask here. By his post here, 
> one could see, that his harddisk or ide connection was not so fine as he 
> previously stated, so we continued to discuss in on 
> de.comp.os.unix.linux.misc and finally could solve the problem by setting a 
> lower udma speed.

What's this got to do with reiserfs again if users are using broken
hardware with multi-metre-long illuminated cables?

> IMHO, almost all of the reported reiserfs problems are due to hardware errors, 
> but some are also due to patches which are enabled by default by 
> distributions like Suse or RedHat.

The patches are not a problem, but not updating the kernel when a
problem is being fixed in the upstream. We've been through this with
dozens of critical components, user-space, kernel-space, kernel support
utilities, go fix the distro.

They - SuSE in particular - won't even fix a security regression they've
introduced into a new release (for instance, into ntpd - 8.2 supported
broadcastclient, 9.0 did not - or openssh, they changed the sshd default
to UsePAM yes and ever since, PermitRootLogin without-password was
without effect and allowed for root logins - and without warning in the
admin's mailbox.).

> every ext2 partition by reiserfs on the next Suse-7.0 installation. Then the 
> problems arrived, since I also exported everything via nfs and since the Suse 
> installer had choosen the 3.5 format without warning me about it, I run into 
> serious trouble and reverted everything that was exported by nfs back to ext2 
> for the next 2 years.

The problem was not 3.5 format but the problem was "kernel bug". IIRC,
it had something to do with inode or dentry caching. I have used
reiserfs-3.5 without NFS problems and I have also been through SL 7.0,
7.3.

It appears SuSE's policy to sell bugfixes as the next release that
happens twice a year at most.

Given that data=ordered is only prudent as it prevents the common
failure cases, it should be the default in testing kernels at any rate.

> should be disabled by default. I wouldn't mind if it becomed included, but 
> marked as experimental, so that one can easily wouldn't include it in a 
> server kernel.

Server kernels in particular need data=ordered - of course, only if it
has stabilized.

-- 
Matthias Andree

Encrypt your mail: my GnuPG key ID is 0x052E7D95