Reiser4 O_DIRECT

Reiser4 O_DIRECT

[Martin Piayda]

Hi,
I'm missing O_DIRECT support in the current Reiser4 implementation (up
to Kernel 2.6.12-rc4-mm).
Calling sys_open(myfile, O_RDWR | O_DIRECT, 0) fails with -22.

Is this support planned, did I miss something, should I get my own
patches? ReiserFS seems to work with O_DIRECT, but not Reiser4, so I
wondered why not.

Regards,
Martin

Re: Reiser4 O_DIRECT

[Vladimir Saveliev]

Hello

On Thu, 2005-05-19 at 21:53, Martin Piayda wrote:
> Hi,
> I'm missing O_DIRECT support in the current Reiser4 implementation (up
> to Kernel 2.6.12-rc4-mm).
> Calling sys_open(myfile, O_RDWR | O_DIRECT, 0) fails with -22.
> 
> Is this support planned, did I miss something, should I get my own
> patches? ReiserFS seems to work with O_DIRECT, but not Reiser4, so I
> wondered why not.
> 

reiser4 has not O_DIRECT support yet.
It will be added when the below are done:
1. reiser4 does not crash in our internal stress tests
2. there are no core linux patches reiser4 depends on and lkml objects
against
3. reiser4 has stable performance

Unfortunately, I can not estimate when those problems will be addressed

> Regards,
> Martin
> 
> 

Re[2]: Reiser4 O_DIRECT

[Pysiak Satriani]

Hello Vladimir,

Friday, May 20, 2005, 10:42:06 AM, you wrote:
> reiser4 has not O_DIRECT support yet.
> It will be added when the below are done:
> 1. reiser4 does not crash in our internal stress tests
I remember Hans saying that r4 is so stable that the developers themselves
can not find any more bugs.

Anyway, best of luck and greetings to the project developers.

I guess the true stabilization will come once r4 is in the kernel
as an experimental fs. Only then the number of users will grow
rapidly. But you already know that, so...

Keep on rocking dudes!

--
Best Regards,
Maciej

Re: Reiser4 O_DIRECT

[Hans Reiser]

What Vladimir failed to say was that it is our recent changes to
accomodate the kernel maintainers that are unstable, we had previously
reached the point where none of our internal tests could make it crash. 
I hope that he did not put these unstable changes on our website for
users to see them without special notes....

Hans

Pysiak Satriani wrote:

>Hello Vladimir,
>
>Friday, May 20, 2005, 10:42:06 AM, you wrote:
>  
>
>>reiser4 has not O_DIRECT support yet.
>>It will be added when the below are done:
>>1. reiser4 does not crash in our internal stress tests
>>    
>>
>I remember Hans saying that r4 is so stable that the developers themselves
>can not find any more bugs.
>
>Anyway, best of luck and greetings to the project developers.
>
>I guess the true stabilization will come once r4 is in the kernel
>as an experimental fs. Only then the number of users will grow
>rapidly. But you already know that, so...
>
>Keep on rocking dudes!
>
>--
>Best Regards,
>Maciej
>
>
>
>
>  
>

Re: Reiser4 O_DIRECT

[mjt]

On Sun, May 22, 2005 at 12:43:52AM -0700, Hans Reiser wrote:
>What Vladimir failed to say was that it is our recent changes to
>accomodate the kernel maintainers that are unstable, we had previously
>reached the point where none of our internal tests could make it crash. 
>I hope that he did not put these unstable changes on our website for
>users to see them without special notes....

This is probably still true for performance as well, yes?

I haven't been testing Reiser4 for too long, I just set up a 32-bit
chroot and chose Reiser4 for it so I may be able to resume my
freelance-toying with it. If I can arrange more spare time.

Any suggestions for performance/latency benchmark suites, preferrably
automated, are welcome, of course ;)

-- 
mjt

Re: Reiser4 O_DIRECT

[Hans Reiser]

Markus Törnqvist wrote:

>On Sun, May 22, 2005 at 12:43:52AM -0700, Hans Reiser wrote:
>  
>
>>What Vladimir failed to say was that it is our recent changes to
>>accomodate the kernel maintainers that are unstable, we had previously
>>reached the point where none of our internal tests could make it crash. 
>>I hope that he did not put these unstable changes on our website for
>>users to see them without special notes....
>>    
>>
>
>This is probably still true for performance as well, yes?
>
>I haven't been testing Reiser4 for too long, I just set up a 32-bit
>chroot and chose Reiser4 for it so I may be able to resume my
>freelance-toying with it. If I can arrange more spare time.
>
>Any suggestions for performance/latency benchmark suites, preferrably
>automated, are welcome, of course ;)
>
>  
>
Something is currently making our performance erratic for multiple
streams of IO.

Re: Reiser4 O_DIRECT

[Martin Piayda]

On So, 2005-05-22 at 20:12 +0300, Markus TXrnqvist wrote:
> On Sun, May 22, 2005 at 12:43:52AM -0700, Hans Reiser wrote:
> >What Vladimir failed to say was that it is our recent changes to
> >accomodate the kernel maintainers that are unstable, we had previously
> >reached the point where none of our internal tests could make it crash. 
> >I hope that he did not put these unstable changes on our website for
> >users to see them without special notes....

Aha? This implies to me there are code-chunks which cause these unstable
scenarios, but should not be included in the patches that are available
to the public. I've never had any crashes although my R4 partition is
heavily used for reading/writing small files.
What is the matter of including O_DIRECT in the stable branch of R4
then? Or how do these recent changes affect the R4 patches, that are
merged into the latest mm-sources (akpm)?

Re: Reiser4 O_DIRECT

[evilninja]

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

mjt@nysv.org wrote:
> 
> Any suggestions for performance/latency benchmark suites, preferrably
> automated, are welcome, of course ;)

fwiw, i did some benchmarks, and will do with new hardware soon:

http://nerdbynature.de/bench/prinz/2.6.12-rc3-mm2/bonnie.html



- --
BOFH excuse #214:

Fluorescent lights are generating negative ions. If turning them off
doesn't work, take them out and put tin foil on the ends.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCliKNC/PVm5+NVoYRAn8fAKDW/zJTq5HGaAjr2G+1RTb++ogsSwCg18Tr
Lwy+LS0LpFUZWMOzMt9fXDk=
=QznS
-----END PGP SIGNATURE-----

Re: Re[2]: Reiser4 O_DIRECT

[Valdis.Kletnieks]

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

On Sat, 21 May 2005 23:49:00 +0200, Pysiak Satriani said:

> I remember Hans saying that r4 is so stable that the developers themselves
> can not find any more bugs.

Which in reality probably means "It *probably* won't eat your data".

Remember that the developers have a limited number of different hardware
configurations, and a limited number of test tools, and a limited number
of ways they use the file system.

So there's probably *plenty* of bugs still to be found - most of them the sort
that nobody will expect, and won't be found until some user's creeping-horror
database application that's written half in Cobol and half in Python does something
totally stupid but legal.....

I've been on both ends - beta tester for software the developers weren't
finding any more bugs in (I filed over 300 bug reports against the product
anyhow), and had users find fatal bugs I couldn't find (my favorite had to be a
user who managed to crash software I wrote by entering a backspace character.
On an IBM 3270 terminal. Which doesn't *HAVE* a transmittable backspace
character - backspace is handled locally in the terminal....)


[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: Reiser4 O_DIRECT

[David Masover]

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

Valdis.Kletnieks@vt.edu wrote:
> On Sat, 21 May 2005 23:49:00 +0200, Pysiak Satriani said:
> 
> 
>>I remember Hans saying that r4 is so stable that the developers themselves
>>can not find any more bugs.
> 
> 
> Which in reality probably means "It *probably* won't eat your data".
> 
> Remember that the developers have a limited number of different hardware
> configurations, and a limited number of test tools, and a limited number
> of ways they use the file system.
> 
> So there's probably *plenty* of bugs still to be found - most of them the sort
> that nobody will expect, and won't be found until some user's creeping-horror
> database application that's written half in Cobol and half in Python does something
> totally stupid but legal.....

This is exactly why it should be in the kernel once the developers can't
find any more bugs.  Marked as experimental, mainly, but in the kernel
where real users can throw cobol/Java/sql bastardizations at it and
break it.

Of course, I've worked on sufficiently few big projects that I'm still
naive enough to believe that unit tests _can_ catch everything, if
they're done right.  I'm sure I'll eventually be proven wrong...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iQIVAwUBQpEiWngHNmZLgCUhAQKsfhAAmIMqe5C76D4TkbEHON261LgFS5wpqe+W
zhe2NlIk8BesA3YhYDFt/4zwQuVMZKkyFH5Np5N1dzfnP0ztpunfovKNApuYz7NH
qxIfbH0QCRHcXX7RrrChLZcpyXy1+hbIa71KmpoaciE30SEOxR3M8DlCO6uIhlGq
kjIJmO0YzIKECSmlHTbZEr0ox23C+fc1kGnH+KWq5qr2kyR0PIhUaqAn8lKMBDE6
vITNk/AodtFZgkJJytEcGU30ZAx4mLH2L/VH1oOM08huEuJjxB8stBlXU09Z/j4o
lowI4gK/N6vRqwHGQ2U0DZSyFqt9nKM72gzfN4gz8yZJgI8BUANLjHEEbnmCnwMJ
nNeoMlyanZPhnk5/C1ISnjL6z+bqWa/SduZExeauXbDYwemJpZzyqOShccsGONbO
Y2dPO3oW/CM0nPjoFTM6TtAGwybA6BsO7WFdyGwq75bCqnN5o2W1oc1o9K5ZiPJ/
obzxmPSMpOcrY/vo7knzBd37oQHBZUFI8lxwaMO+GgZaBzSOVDVaCEtQzBc98MPP
JHNJXmeOWUI0KYVDyd5ACjlhjjvpp0NEGgbMEqNgZy6oNmP734YSUeIVBONpPg2g
/ra+qyL/zji21r93bNUhuIvoX1EUl0/FvFk+0q1S3P5DaCBpn8vz8jqO1Rr3ZvWb
Qd3c53MrHZE=
=b8kU
-----END PGP SIGNATURE-----

Re: Reiser4 O_DIRECT

[Valdis.Kletnieks]

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

On Sun, 22 May 2005 19:22:51 CDT, David Masover said:

> This is exactly why it should be in the kernel once the developers can't
> find any more bugs.  Marked as experimental, mainly, but in the kernel
> where real users can throw cobol/Java/sql bastardizations at it and
> break it.

Oh, I agree there - it's at a point where it *should* be in a -mm kernel,
or a -linus wrapped with a Kconfig 'depends on EXPERIMENTAL'. (I'll let
Andrew and Linus make *THAT* decision ;)

I'm just worried about PHB managers lurking on the list and reading "so stable
even the *developers* can't break it" as "it's *really* good and solid" rather
than "we need *other* people to break all the stuff we forgot to break" ;)


[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: Reiser4 O_DIRECT

[mjt]

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

On Sun, May 22, 2005 at 07:22:51PM -0500, David Masover wrote:
>
>This is exactly why it should be in the kernel once the developers can't
>find any more bugs.  Marked as experimental, mainly, but in the kernel
>where real users can throw cobol/Java/sql bastardizations at it and
>break it.

Sure.

Don't get me wrong on this, because I've voiced my opinion about
the new development model failing us, with stuff getting a bit
too lively in -mm and merged into stable a bit too fast for comfort.

Still, this new model would allow someone to merge Reiser4 into
vanilla with ease, whereas on the traditional model, kicking
an experimental fs from the dev tree might have been a difficult
political move.

Thus it must be anounced in a way that doesn't scare people away
"oh no this is yet another broken pile from -mm, we don't want it!"
but invite them "kickass, a file system that's stable enough to
be merged, with EXPERIMENTAL just pro forma on it"

>Of course, I've worked on sufficiently few big projects that I'm still
>naive enough to believe that unit tests _can_ catch everything, if
>they're done right.  I'm sure I'll eventually be proven wrong...

My take on testing is that I leave it to the real professionals and
with cases like Reiser4, I just blindly do what I'm told and see if
I break anything.

I'm sure a testing professional will happily prove you wrong ;)

-- 
mjt


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Reiser4 O_DIRECT

[Valdis.Kletnieks]

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

On Mon, 23 May 2005 12:52:12 +0300, Markus =?UNKNOWN?Q?T=F6rnqvist?= said:
> On Sun, May 22, 2005 at 07:22:51PM -0500, David Masover wrote:
> >Of course, I've worked on sufficiently few big projects that I'm still
> >naive enough to believe that unit tests _can_ catch everything, if
> >they're done right.  I'm sure I'll eventually be proven wrong...
> I'm sure a testing professional will happily prove you wrong ;)

It's *never* the testing professional that disproves "unit tests can catch everything".

It's the guy with the creeping-horror Cobol/Python database that finds the stuff
that unit tests can't catch.. ;)


[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: Reiser4 O_DIRECT

[Hans Reiser]

Valdis.Kletnieks@vt.edu wrote:

>On Mon, 23 May 2005 12:52:12 +0300, Markus =?UNKNOWN?Q?T=F6rnqvist?= said:
>  
>
>>On Sun, May 22, 2005 at 07:22:51PM -0500, David Masover wrote:
>>    
>>
>>>Of course, I've worked on sufficiently few big projects that I'm still
>>>naive enough to believe that unit tests _can_ catch everything, if
>>>they're done right.  I'm sure I'll eventually be proven wrong...
>>>      
>>>
>>I'm sure a testing professional will happily prove you wrong ;)
>>    
>>
>
>It's *never* the testing professional that disproves "unit tests can catch everything".
>
>It's the guy with the creeping-horror Cobol/Python database that finds the stuff
>that unit tests can't catch.. ;)
>
>  
>
My favorite for version 3 (we now test for this in v4 testing) was
mozilla truncating files longer rather than shorter.  Legal but was not
tested for....

fsx is now the standard file system test tool.  It still misses a LOT of
stuff.

Hans

Re: Reiser4 O_DIRECT

[David Masover]

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

Hans Reiser wrote:
> Valdis.Kletnieks@vt.edu wrote:
> 
> 
>>On Mon, 23 May 2005 12:52:12 +0300, Markus =?UNKNOWN?Q?T=F6rnqvist?= said:
>> 
>>
>>
>>>On Sun, May 22, 2005 at 07:22:51PM -0500, David Masover wrote:
>>>   
>>>
>>>
>>>>Of course, I've worked on sufficiently few big projects that I'm still
>>>>naive enough to believe that unit tests _can_ catch everything, if
>>>>they're done right.  I'm sure I'll eventually be proven wrong...
>>>>     
>>>>
>>>
>>>I'm sure a testing professional will happily prove you wrong ;)
>>>   
>>>
>>
>>It's *never* the testing professional that disproves "unit tests can catch everything".
>>
>>It's the guy with the creeping-horror Cobol/Python database that finds the stuff
>>that unit tests can't catch.. ;)
>>
>> 
>>
> 
> My favorite for version 3 (we now test for this in v4 testing) was
> mozilla truncating files longer rather than shorter.  Legal but was not
> tested for....

I see how that works.  I'm going to have to think a bit harder now.

My feeling is that you create the standard as you create the test, not
the other way around.  If the test works, then there are by definition
few bugs if any in the system itself -- any other bugs are actually in
the application, not the system.

Still, your true ignorance is what you don't know that you don't know.
There's always something that you didn't think to think of.  And I'm
thinking of putting that as a disclaimer on all my mail...

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iQIVAwUBQpOeN3gHNmZLgCUhAQK5lBAAmaZCXIlaSaD3aVXSyH3tdiEPS9UEOdvH
eVtmvaM5ZO5ao1aebaodAmVSqmzEKbLCeNCaoa6ZTsFi6uHC21hOBTpqHxW0i94Y
PN22cw3ZTtpPU2KUWB7dTHqI9uz5JUMkMnFg7moRqH/bDzk+XBeNH9xgFnkzYjuj
g3nMvJUGggbNCX0XLsDAiQnOUe/rzvgIMP4LtcWi9UxzNKa//PfLBM/dO6ry77R7
PD404BVxXy5OHgJc8L4D2FLB6fdOTX7rUFC7GYqGhl9pdv8HGxOrQ+AkbhFF2F0/
hgXeX/7mMtFehZD19i8A/+uglR+qqw+1P8zsF8AoMmoRwhhDA25enH6knImSQh9q
Ppzht93CABh0WtHM/jHkSM9Dpla9u67FMqlsFV5eRWMLXqTK/OVcm+zGM4pKPBcL
8gXiEdpiqj/pYjMjsvIhxwyVIpEIZrpo6V0zilimHMaFuiTtZ9M8KrKMhTWx/xAp
upLAV8e17NJ8ew+I1ChHqXhDgFOxh1uzVkY2iCVsjjVEsNJbPwsb1jMg35RhC+RW
1L/7dUp7CPzd5xhE3oSoKDhGkTDKKQOhfX1CkWIgTGGmhc2nqQSmriK6wr0dxyHM
R2vaRbvlKWSH5r/JNw9vEyWKIDRuoQdEy+kdEhvBF1Y61HMGUqacdOlLoM+ozVZA
g3GPsl/jixg=
=00kz
-----END PGP SIGNATURE-----

Re: Reiser4 O_DIRECT

[Valdis.Kletnieks]

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

On Tue, 24 May 2005 16:35:51 CDT, David Masover said:

> My feeling is that you create the standard as you create the test, not
> the other way around.  If the test works, then there are by definition
> few bugs if any in the system itself -- any other bugs are actually in
> the application, not the system.

That's even worse.  Then if somebody bodgers it all up with some corner case
that your test system didn't cover, you're by definition screwed, as the
standard won't say what it *SHOULD* do....

Consider the vast philosophical difference between "This is what the FS *should*
do" and "This is what we tested the FS for".  You want the standard to be the
first, not the second.....

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: Reiser4 O_DIRECT

[David Masover]

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

Valdis.Kletnieks@vt.edu wrote:
> On Tue, 24 May 2005 16:35:51 CDT, David Masover said:
> 
> 
>>My feeling is that you create the standard as you create the test, not
>>the other way around.  If the test works, then there are by definition
>>few bugs if any in the system itself -- any other bugs are actually in
>>the application, not the system.
> 
> 
> That's even worse.  Then if somebody bodgers it all up with some corner case
> that your test system didn't cover, you're by definition screwed, as the
> standard won't say what it *SHOULD* do....
> 
> Consider the vast philosophical difference between "This is what the FS *should*
> do" and "This is what we tested the FS for".  You want the standard to be the
> first, not the second.....

No, you want them all to be the same thing.  You want "This is what we
tested the FS for" to be broad enough that you really don't have very
many bugs at any stage in development.

But then, I'm being overly optimistic.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iQIVAwUBQpO4ungHNmZLgCUhAQKDIg//S5gF75thisHjI7DjzecyVCjhvSJxNIX6
aTljjVP9QjNu85X2q7QFHvqoKL8frrn+nTZ+70gUdN9FQL4S7nn0SbtBED/Rra9A
C2vPDr89yoCOpP1mTVw/0URnDtwV3AmFxwnMYrfz1nfBReCUcYKeY6NBUNeS/eWV
h51FvSc10r7dxsI287svUlxpNTeyySogvjhhTa6C2v1kkLAyvgJ5AEmTDXkE01k9
aaJ+YJgAfgu5l1TRQHpZm9ck7ikBkXqGMrc/+vb6L3AHnMGfbinIDN8x8UD/l7XB
0nF4sgh+h30bjwF08+B5vc6SQeTSKL/L5ZxUg6J3G0GhduS9wAYb5bvGxZUYd79X
Va+/M1kWjFF14o9ORGIfsNDNXxzM1dPL+0JjtnDwnqF2ahuKEYfIq67A4ggRFL3+
HkZb1p4cVi0YaGG39nADEiOOddyL/5vQxIyRgbY/j7gZWORZd3XS0tYGRfyz4lBF
8WLLvoKtO3PEVF89KSFj4nOUR9piIbHt96zEckbX11v4igskl5Uf9VZzTfuUzzlY
Fhr22FPJLCBmYQGljjBguwOExYHbATCPaYjFwl99SHx7XAAc0ezz5qwP+UUMcRUc
riiYaHN0MgSctz3h/D1KeiUvyMjpm2QTKOAw59h0/XB0owfnpovnW9xznPIlu5e4
f4CR1VQPMfI=
=c/WP
-----END PGP SIGNATURE-----