reiser4 data journalling?

reiser4 data journalling?

[Tupshin Harper]

Will reiser4 have options equivalent to ext3's data=journal and 
data=ordered options? My understanding is that reiser4(and reiser3) do 
the equivalent of ext3's writeback mode(correct?). Any plans for the 
other modes in order to maximize data integrity?

-Tupshin

Re: reiser4 data journalling?

[Nikita Danilov]

Tupshin Harper writes:
 > Will reiser4 have options equivalent to ext3's data=journal and 
 > data=ordered options? My understanding is that reiser4(and reiser3) do 
 > the equivalent of ext3's writeback mode(correct?). Any plans for the 

reiserfs has meta-data only journalling by default (equivalent to
writeback mode), and optionally supports full data journalling (Chris
patches).

reiser4 supports full data journalling only, but it is still faster than
ext3-writeback.

Look at http://www.namesys.com/benchmarks.html for last benchmarking
results.

 > other modes in order to maximize data integrity?
 > 
 > -Tupshin
 > 

Nikita.

Re: reiser4 data journalling?

[Hans Reiser]

Nikita Danilov wrote:

>Tupshin Harper writes:
> > Will reiser4 have options equivalent to ext3's data=journal and 
> > data=ordered options? My understanding is that reiser4(and reiser3) do 
> > the equivalent of ext3's writeback mode(correct?). Any plans for the 
>
>reiserfs has meta-data only journalling by default (equivalent to
>writeback mode), and optionally supports full data journalling (Chris
>patches).
>
>reiser4 supports full data journalling only
>
full data journaling means that if you perform writes that are 4k or 
less, and page align them, they will be performed atomically. 

Reiser4 is a fully atomic filesystem, and that means that you can 
perform a set of filesystem operations of any size, and they will be 
performed atomically.  By default, every fs system call is performed 
atomically.

Please describe reiser4 as an atomic filesystem, not as (just) a data 
journaling filesystem, ok?

>, but it is still faster than
>ext3-writeback.
>
>Look at http://www.namesys.com/benchmarks.html for last benchmarking
>results.
>
> > other modes in order to maximize data integrity?
> > 
> > -Tupshin
> > 
>
>Nikita.
>
>
>  
>


-- 
Hans

Re: reiser4 data journalling?

[Tom Vier]

On Fri, Aug 29, 2003 at 12:48:36AM +0400, Hans Reiser wrote:
> full data journaling means that if you perform writes that are 4k or 
> less, and page align them, they will be performed atomically. 

would it be much more difficult to allow non-page aligned bufs to be written
atomically? a fully atomic fs would be very nice. otherwise, a lot of utils
and shell builtins would have to be modded to insure page alignment. it
would be neat if all the regular builtins (cp, mv, ln) were atomic. of
course, even neater would be the ability to group multiple ops into one
atomic action. (this is probably already planned - it's been a while since i
read the reiserfs4 paper on the namesys site.)

-- 
Tom Vier <tmv@comcast.net>
DSA Key ID 0xE6CB97DA

Re: reiser4 data journalling?

[Hans Reiser]

Tom Vier wrote:

>On Fri, Aug 29, 2003 at 12:48:36AM +0400, Hans Reiser wrote:
>  
>
>>full data journaling means that if you perform writes that are 4k or 
>>less, and page align them, they will be performed atomically. 
>>    
>>
>
>would it be much more difficult to allow non-page aligned bufs to be written
>atomically? a fully atomic fs would be very nice. otherwise, a lot of utils
>and shell builtins would have to be modded to insure page alignment. it
>would be neat if all the regular builtins (cp, mv, ln) were atomic. of
>course, even neater would be the ability to group multiple ops into one
>atomic action. (this is probably already planned - it's been a while since i
>read the reiserfs4 paper on the namesys site.)
>
>  
>
reiser4 does all this that you ask for, although the user space API is 
not yet compiling;-)

-- 
Hans

Re: reiser4 data journalling?

[Mike Fedyk]

On Fri, Aug 29, 2003 at 04:21:01AM +0400, Hans Reiser wrote:
> Tom Vier wrote:
> >would it be much more difficult to allow non-page aligned bufs to be 
> >written
> >atomically? a fully atomic fs would be very nice. otherwise, a lot of utils
> >and shell builtins would have to be modded to insure page alignment. it
> >would be neat if all the regular builtins (cp, mv, ln) were atomic. of
> >course, even neater would be the ability to group multiple ops into one
> >atomic action. (this is probably already planned - it's been a while since 
> >i
> >read the reiserfs4 paper on the namesys site.)
> >
> > 
> >
> reiser4 does all this that you ask for, although the user space API is 
> not yet compiling;-)
> 

So you can have one 5k memory area that spans two pages, and it will act on
them atomically?  Or does that mean that the utils are already page aligned
by other kernel mechanisims?  Or that they'll have to use the reiser API to
do some of the above (other than the op grouping)?

Re: reiser4 data journalling?

[Oleg Drokin]

Hello!

On Thu, Aug 28, 2003 at 06:23:22PM -0700, Mike Fedyk wrote:

> So you can have one 5k memory area that spans two pages, and it will act on
> them atomically?  Or does that mean that the utils are already page aligned
> by other kernel mechanisims?  Or that they'll have to use the reiser API to
> do some of the above (other than the op grouping)?

Data does not need to be page aligned for atomic operations.

Bye,
    Oleg

Re: reiser4 data journalling?

[Hans Reiser]

Oleg Drokin wrote:

>Hello!
>
>On Thu, Aug 28, 2003 at 06:23:22PM -0700, Mike Fedyk wrote:
>
>  
>
>>So you can have one 5k memory area that spans two pages, and it will act on
>>them atomically?  Or does that mean that the utils are already page aligned
>>by other kernel mechanisims?  Or that they'll have to use the reiser API to
>>do some of the above (other than the op grouping)?
>>    
>>
>
>Data does not need to be page aligned for atomic operations.
>
>Bye,
>    Oleg
>
>
>  
>
in reiser4

-- 
Hans

Re: reiser4 data journalling?

[Nikita Danilov]

Hans Reiser writes:
 > Oleg Drokin wrote:
 > 
 > >Hello!
 > >
 > >On Thu, Aug 28, 2003 at 06:23:22PM -0700, Mike Fedyk wrote:
 > >
 > >  
 > >
 > >>So you can have one 5k memory area that spans two pages, and it will act on
 > >>them atomically?  Or does that mean that the utils are already page aligned
 > >>by other kernel mechanisims?  Or that they'll have to use the reiser API to
 > >>do some of the above (other than the op grouping)?
 > >>    
 > >>
 > >
 > >Data does not need to be page aligned for atomic operations.
 > >
 > >Bye,
 > >    Oleg
 > >
 > >
 > >  
 > >
 > in reiser4

Why?

 > 
 > -- 
 > Hans
 > 

Nikita.

 > 

Re: reiser4 data journalling?

[Nikita Danilov]

Nikita Danilov writes:
 > Hans Reiser writes:
 >  > Oleg Drokin wrote:
 >  > 
 >  > >Hello!
 >  > >
 >  > >On Thu, Aug 28, 2003 at 06:23:22PM -0700, Mike Fedyk wrote:
 >  > >
 >  > >  
 >  > >
 >  > >>So you can have one 5k memory area that spans two pages, and it will act on
 >  > >>them atomically?  Or does that mean that the utils are already page aligned
 >  > >>by other kernel mechanisims?  Or that they'll have to use the reiser API to
 >  > >>do some of the above (other than the op grouping)?
 >  > >>    
 >  > >>
 >  > >
 >  > >Data does not need to be page aligned for atomic operations.
 >  > >
 >  > >Bye,
 >  > >    Oleg
 >  > >
 >  > >
 >  > >  
 >  > >
 >  > in reiser4
 > 
 > Why?

I mean, neither it need to be in ext[23].

 > 
 >  > 
 >  > -- 
 >  > Hans
 >  > 
 > 

Nikita.

 > 
 >  > 

Re: reiser4 data journalling?

[Hans Reiser]

Nikita Danilov wrote:

>Hans Reiser writes:
> > Oleg Drokin wrote:
> > 
> > >Hello!
> > >
> > >On Thu, Aug 28, 2003 at 06:23:22PM -0700, Mike Fedyk wrote:
> > >
> > >  
> > >
> > >>So you can have one 5k memory area that spans two pages, and it will act on
> > >>them atomically?  Or does that mean that the utils are already page aligned
> > >>by other kernel mechanisims?  Or that they'll have to use the reiser API to
> > >>do some of the above (other than the op grouping)?
> > >>    
> > >>
> > >
> > >Data does not need to be page aligned for atomic operations.
> > >
> > >Bye,
> > >    Oleg
> > >
> > >
> > >  
> > >
> > in reiser4
>
>Why?
>
> 
>
Because atomicity in ext3 basically consists of guaranteeing that the filesystem is consistent, and due to the disk drive implementation 4k blocks are written atomically.  So, if you span more than one block, it is not guaranteed to be atomic.

Someone should correct me if I got it wrong, as ext3 is not my specialty....

RE: reiser4 data journalling?

[system_lists]

> -----Mensaje original-----
> De: Hans Reiser [mailto:reiser@namesys.com]
> Enviado el: viernes, 29 de agosto de 2003 23:43
> Para: Nikita Danilov
> CC: Oleg Drokin; Mike Fedyk; Tom Vier; Reiserfs List
> Asunto: Re: reiser4 data journalling?
> 
> Nikita Danilov wrote:
> 
> >Hans Reiser writes:
> > > Oleg Drokin wrote:
> > >
> > > >Hello!
> > > >
> > > >On Thu, Aug 28, 2003 at 06:23:22PM -0700, Mike Fedyk wrote:
> > > >
> > > >
> > > >
> > > >>So you can have one 5k memory area that spans two pages, and it will
> act on
> > > >>them atomically?  Or does that mean that the utils are already page
> aligned
> > > >>by other kernel mechanisims?  Or that they'll have to use the reiser
> API to
> > > >>do some of the above (other than the op grouping)?
> > > >>
> > > >>
> > > >
> > > >Data does not need to be page aligned for atomic operations.
> > > >
> > > >Bye,
> > > >    Oleg
> > > >
> > > >
> > > >
> > > >
> > > in reiser4
> >
> >Why?
> >
> >
> >
> Because atomicity in ext3 basically consists of guaranteeing that the
> filesystem is consistent, and due to the disk drive implementation 4k
> blocks are written atomically.  So, if you span more than one block, it is
> not guaranteed to be atomic.
> 
> Someone should correct me if I got it wrong, as ext3 is not my
> specialty....
> 

I think that is right.

Re: reiser4 data journalling?

[Andi Kleen]

Hans Reiser <reiser@namesys.com> writes:
>>
> Because atomicity in ext3 basically consists of guaranteeing that the filesystem is consistent, and due to the disk drive implementation 4k blocks are written atomically.  So, if you span more than one block, it is not guaranteed to be atomic.

I was told most modern disks run with 32-64K blocks internally.

4K is very unlikely.

Of course they don't always guarantee that a write of such a block
is atomic, but then they also don't guarantee it for 4K.

The only sure way is to wait for the disk telling you it is finished 
(= use write barriers)  and/or turn the write buffer off.
Even then you have to hope that the disk firmware doesn't lie to you.

-Andi

Re: reiser4 data journalling?

[Hans Reiser]

Andi Kleen wrote:

>Hans Reiser <reiser@namesys.com> writes:
>  
>
>>Because atomicity in ext3 basically consists of guaranteeing that the filesystem is consistent, and due to the disk drive implementation 4k blocks are written atomically.  So, if you span more than one block, it is not guaranteed to be atomic.
>>    
>>
>
>I was told most modern disks run with 32-64K blocks internally.
>
This is very interesting, it would explain something that has puzzled me 
for a long time about 64k being the optimal transfer size.

>4K is very unlikely.
>
>Of course they don't always guarantee that a write of such a block
>is atomic, but then they also don't guarantee it for 4K.
>
What they do in the event of power loss is the big unclear for hard 
drives.  Maybe I should ask for government funding to test hard drives 
for what they actually do, and how they handle power loss.;-)   Somebody 
needs to test these folks.....

Most filesystems are designed based around the assumption that ecc on 
the drive will detect failed writes with 4k granularity.  If I remember 
right, some folks on this list have said some things suggesting that for 
some IBM drives a power failure can cause a more than 4k chunk to go 
bad, and that this can be a problem for filesystem consistency.

It would probably be nice for the OS and the drive to use the same block 
size..... or at least interesting to experiment with.

>The only sure way is to wait for the disk telling you it is finished 
>(= use write barriers)  and/or turn the write buffer off.
>Even then you have to hope that the disk firmware doesn't lie to you.
>
>-Andi
>
>
>  
>


-- 
Hans

Re: reiser4 data journalling?

[Tom Vier]

On Wed, Sep 03, 2003 at 02:21:20AM +0400, Hans Reiser wrote:
> some IBM drives a power failure can cause a more than 4k chunk to go 
> bad, and that this can be a problem for filesystem consistency.

this thread talks about fsync, wb's, etc, and i think also mentions the
problem w/ an ibm drive. if not, it's in another thread from around the same
time. i forgot i had this linked on wipe.sf.net (shameless plug ;).

http://www.ussg.iu.edu/hypermail/linux/kernel/0103.0/0331.html

-- 
Tom Vier <tmv@comcast.net>
DSA Key ID 0xE6CB97DA

Re: reiser4 data journalling?

[Hans Reiser]

Mike Fedyk wrote:

>On Fri, Aug 29, 2003 at 04:21:01AM +0400, Hans Reiser wrote:
>  
>
>>Tom Vier wrote:
>>    
>>
>>>would it be much more difficult to allow non-page aligned bufs to be 
>>>written
>>>atomically? a fully atomic fs would be very nice. otherwise, a lot of utils
>>>and shell builtins would have to be modded to insure page alignment. it
>>>would be neat if all the regular builtins (cp, mv, ln) were atomic. of
>>>course, even neater would be the ability to group multiple ops into one
>>>atomic action. (this is probably already planned - it's been a while since 
>>>i
>>>read the reiserfs4 paper on the namesys site.)
>>>
>>>
>>>
>>>      
>>>
>>reiser4 does all this that you ask for, although the user space API is 
>>not yet compiling;-)
>>
>>    
>>
>
>So you can have one 5k memory area that spans two pages, and it will act on
>them atomically?
>
we deal with files not memory areas.

>  Or does that mean that the utils are already page aligned
>by other kernel mechanisims?  Or that they'll have to use the reiser API to
>do some of the above (other than the op grouping)?
>
>
>  
>


-- 
Hans

Re: reiser4 data journalling?

[Lars Marowsky-Bree]

On 2003-08-28T20:18:14,
   Tom Vier <tmv@comcast.net> said:

> and shell builtins would have to be modded to insure page alignment. it
> would be neat if all the regular builtins (cp, mv, ln) were atomic.

mv (ie, rename), ln and rm have always been atomic. That's a POSIX
requirement.

The new thing with reiserfs4 seems to be that if you do a write of, say,
1M size in the atomic way, another reading process will either see all
of the write or none of the write to have taken place.

(Right now, you could see a 'partial' read, where some pages from the
write have been written already while others return the old data.)

And apparently, you can say "begin transaction" and "commit / abort
transaction" to achieve the same for multiple operations as a group.

Hans, does that support nested transactions, too?

And one thing has slipped from my mind: How do I enter a transaction? is
it like chroot(), or a task-specific thing, how can child processes
participate in the transaction etc?


Sincerely,
    Lars Marowsky-Brée <lmb@suse.de>

-- 
High Availability & Clustering		ever tried. ever failed. no matter.
SuSE Labs				try again. fail again. fail better.
Research & Development, SuSE Linux AG		-- Samuel Beckett

Re: reiser4 data journalling?

[Hans Reiser]

Lars Marowsky-Bree wrote:

>On 2003-08-28T20:18:14,
>   Tom Vier <tmv@comcast.net> said:
>
>  
>
>>and shell builtins would have to be modded to insure page alignment. it
>>would be neat if all the regular builtins (cp, mv, ln) were atomic.
>>    
>>
>
>mv (ie, rename), ln and rm have always been atomic. That's a POSIX
>requirement.
>
Programs that need atomicity find it inconvenient that only one mv, or 
one ln, and or one rm, or one 4k write of a block, are atomic operations.

>The new thing with reiserfs4 seems to be that if you do a write of, say,
>1M size in the atomic way, 
>

>another reading process will either see all
>of the write or none of the write to have taken place.
>
No, isolation is not yet implemented and won't be unless we come up with 
some more funding from somewhere.  The txnmgr seems to be structured to 
handle isolation, but....

The new thing with reiser4 is that if you do that write of 1MB to a 
file, and perhaps updates to 63 other files as well, as part of an atom, 
it will either all survive a crash, or none of it will.  We have 
considered using the term "transcrash" for this.

>(Right now, you could see a 'partial' read, where some pages from the
>write have been written already while others return the old data.)
>
>And apparently, you can say "begin transaction" and "commit / abort
>transaction" to achieve the same for multiple operations as a group.
>
>Hans, does that support nested transactions, too?
>
>And one thing has slipped from my mind: How do I enter a transaction? is
>it like chroot(), or a task-specific thing, how can child processes
>participate in the transaction etc?
>
>
>Sincerely,
>    Lars Marowsky-Brée <lmb@suse.de>
>
>  
>


-- 
Hans

Re: reiser4 data journalling?

[Lars Marowsky-Bree]

On 2003-09-03T02:17:50,
   Hans Reiser <reiser@namesys.com> said:

> No, isolation is not yet implemented and won't be unless we come up with 
> some more funding from somewhere.  The txnmgr seems to be structured to 
> handle isolation, but....

Ah, okay. Sorry, I think I had older plans in mind and hadn't checked
how far the current roadmap matched up to them ;-)

> The new thing with reiser4 is that if you do that write of 1MB to a 
> file, and perhaps updates to 63 other files as well, as part of an atom, 
> it will either all survive a crash, or none of it will.  We have 
> considered using the term "transcrash" for this.

So it's ACD and not ACID ;-) Sounds good. How is this weak transaction
exported to userspace, ie how do I signal BEGIN and COMMIT/ABORT?



Sincerely,
    Lars Marowsky-Brée <lmb@suse.de>

-- 
High Availability & Clustering		ever tried. ever failed. no matter.
SuSE Labs				try again. fail again. fail better.
Research & Development, SuSE Linux AG		-- Samuel Beckett

Re: reiser4 data journalling?

[Hans Reiser]

Lars Marowsky-Bree wrote:

>On 2003-09-03T02:17:50,
>   Hans Reiser <reiser@namesys.com> said:
>
>  
>
>>No, isolation is not yet implemented and won't be unless we come up with 
>>some more funding from somewhere.  The txnmgr seems to be structured to 
>>handle isolation, but....
>>    
>>
>
>Ah, okay. Sorry, I think I had older plans in mind and hadn't checked
>how far the current roadmap matched up to them ;-)
>
>  
>
>>The new thing with reiser4 is that if you do that write of 1MB to a 
>>file, and perhaps updates to 63 other files as well, as part of an atom, 
>>it will either all survive a crash, or none of it will.  We have 
>>considered using the term "transcrash" for this.
>>    
>>
>
>So it's ACD and not ACID ;-) Sounds good. How is this weak transaction
>exported to userspace, ie how do I signal BEGIN and COMMIT/ABORT?
>
>
>
>Sincerely,
>    Lars Marowsky-Brée <lmb@suse.de>
>
>  
>
sys_reiser4 allows various operations such as assignment, and 
transactions are indicated using a delimiter.  I am still trying to 
figure out what is the best delimiter to use, it needs to be a delimiter 
pair, but what?

Perhaps t{ and }t

?

I worry that users will let a legitimate t variable name get too close 
to the {}'s.....

There is a symbol shortage unfortunately.

Probably I should use x{ and }x as a convention for new kinds of 
delimiters, and let x be t in the case of delimiting transactions.

-- 
Hans