journal size reiserfs vs reiser4

journal size reiserfs vs reiser4

[Thomas Kuther]

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

Hello People!

Just got a new harddrive and as i'm pretty pleased with reiser4 i
thought i'll make it reiser4. But then i realized that it uses almost
1/6 of the hd "for nothing"

mkfs.reiser4 /dev/hde1:
/dev/hde1  reiser4    222G  7,5M  222G   1% /shared

mkfs.reiserfs
/dev/hde1 reiserfs    233G   33M  233G   1% /shared

somehow i had in mind that reiser4 should use much less space than
reiserfs, but it's exactly the other way round. Loosing 17GB of an
250GB disk is hard anyway. but loosing 28GB is simply no go.

Now do i need to pass any special options to mkfs.reiser4 or why is
that? i'm using reiser4progs 1.0.4

Thanks in advance
Tom

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

Re: journal size reiserfs vs reiser4

[Thomas Kuther]

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

On Thu, 1 Sep 2005 13:46:04 +0200
Thomas Kuther <gimpel@sonnenkinder.org> wrote:

> Hello People!
> 
> Just got a new harddrive and as i'm pretty pleased with reiser4 i
> thought i'll make it reiser4. But then i realized that it uses almost
> 1/6 of the hd "for nothing"
> 
> mkfs.reiser4 /dev/hde1:
> /dev/hde1  reiser4    222G  7,5M  222G   1% /shared
> 
> mkfs.reiserfs
> /dev/hde1 reiserfs    233G   33M  233G   1% /shared
> 
> somehow i had in mind that reiser4 should use much less space than
> reiserfs, but it's exactly the other way round. Loosing 17GB of an
> 250GB disk is hard anyway. but loosing 28GB is simply no go.
> 
> Now do i need to pass any special options to mkfs.reiser4 or why is
> that? i'm using reiser4progs 1.0.4
> 
> Thanks in advance
> Tom

OK found out one thing:
Disk /dev/hde: 250.0 GB, 250059350016 bytes <-- crap! 

# echo "250059350016/1024/1024/1024" | bc
232
^^
but that still doesn't explain why df only sees 222 when formatted with
reiser4.

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

Re: journal size reiserfs vs reiser4

[Vladimir V. Saveliev]

Hello

Thomas Kuther wrote:
> On Thu, 1 Sep 2005 13:46:04 +0200
> Thomas Kuther <gimpel@sonnenkinder.org> wrote:
> 
>>Hello People!
>>
>>Just got a new harddrive and as i'm pretty pleased with reiser4 i
>>thought i'll make it reiser4. But then i realized that it uses almost
>>1/6 of the hd "for nothing"
>>
>>mkfs.reiser4 /dev/hde1:
>>/dev/hde1  reiser4    222G  7,5M  222G   1% /shared
>>
>>mkfs.reiserfs
>>/dev/hde1 reiserfs    233G   33M  233G   1% /shared
>>
>>somehow i had in mind that reiser4 should use much less space than
>>reiserfs, but it's exactly the other way round. Loosing 17GB of an
>>250GB disk is hard anyway. but loosing 28GB is simply no go.
>>
>>Now do i need to pass any special options to mkfs.reiser4 or why is
>>that? i'm using reiser4progs 1.0.4
>>
>>Thanks in advance
>>Tom
> 
> OK found out one thing:
> Disk /dev/hde: 250.0 GB, 250059350016 bytes <-- crap! 
> 
> # echo "250059350016/1024/1024/1024" | bc
> 232
> ^^
> but that still doesn't explain why df only sees 222 when formatted with
> reiser4.

reiser4 reserves 5% of disk space for its internal needs.

Re: journal size reiserfs vs reiser4

[PFC]

>>> 250GB disk

Well, 250GB is the "marketing capacity", the real formatted capacity is  
always less (ask fdisk) also of course you have 1024 vs 1000

> reiser4 reserves 5% of disk space for its internal needs.

	So, do you mean this 5% is for metadata, and thus it would be used anyway  
on any other filesystem as files are written, and thus it makes absolutely  
no difference ?

Re: journal size reiserfs vs reiser4

[Thomas Kuther]

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

On Thu, 01 Sep 2005 16:53:32 +0400
"Vladimir V. Saveliev" <vs@namesys.com> wrote:

> Hello
> 
> Thomas Kuther wrote:
> > On Thu, 1 Sep 2005 13:46:04 +0200
> > Thomas Kuther <gimpel@sonnenkinder.org> wrote:
> > 
> >>Hello People!
> >>
> >>Just got a new harddrive and as i'm pretty pleased with reiser4 i
> >>thought i'll make it reiser4. But then i realized that it uses
> >>almost 1/6 of the hd "for nothing"
> >>
> >>mkfs.reiser4 /dev/hde1:
> >>/dev/hde1  reiser4    222G  7,5M  222G   1% /shared
> >>
> >>mkfs.reiserfs
> >>/dev/hde1 reiserfs    233G   33M  233G   1% /shared
> >>
> >>somehow i had in mind that reiser4 should use much less space than
> >>reiserfs, but it's exactly the other way round. Loosing 17GB of an
> >>250GB disk is hard anyway. but loosing 28GB is simply no go.
> >>
> >>Now do i need to pass any special options to mkfs.reiser4 or why is
> >>that? i'm using reiser4progs 1.0.4
> >>
> >>Thanks in advance
> >>Tom
> > 
> > OK found out one thing:
> > Disk /dev/hde: 250.0 GB, 250059350016 bytes <-- crap! 
> > 
> > # echo "250059350016/1024/1024/1024" | bc
> > 232
> > ^^
> > but that still doesn't explain why df only sees 222 when formatted
> > with reiser4.
> 
> reiser4 reserves 5% of disk space for its internal needs.
> 

Ah OK, that computes. So i'll go with reiserfs on that big one (11 GB
for internal stuff is too much i have to admit).

Thanks!
Tom

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

Re: journal size reiserfs vs reiser4

[Peter Staubach]

>>reiser4 reserves 5% of disk space for its internal needs.
>>

5% of today's big disks seems a little excessive.  Does reiser4 really need
that much space or would less also suffice without compromising performance?

Is there research available which makes up the basis for the 5% number?

    Thanx...

       ps

Re: journal size reiserfs vs reiser4

[Thomas Kuther]

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

On Thu, 01 Sep 2005 15:03:43 +0200
PFC <lists@boutiquenumerique.com> wrote:

> 
> >>> 250GB disk
> 
> Well, 250GB is the "marketing capacity", the real formatted capacity
> is always less (ask fdisk) also of course you have 1024 vs 1000
> 
yeah see my 2. mail - 233 GB is the true (1024 based) size of the disk

> > reiser4 reserves 5% of disk space for its internal needs.
> 
> 	So, do you mean this 5% is for metadata, and thus it would be
> used anyway on any other filesystem as files are written, and thus it
> makes absolutely no difference ?
> 
> 
humm.. interesting point. maybe there are starting things like
blocksize and journal size to play a role?

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

Re: journal size reiserfs vs reiser4

[Marcel Hilzinger]

Am Donnerstag, 1. September 2005 15:05 schrieb Thomas Kuther:
> On Thu, 01 Sep 2005 16:53:32 +0400
>
> "Vladimir V. Saveliev" <vs@namesys.com> wrote:
> > Hello
> >
[...]
> >
> > reiser4 reserves 5% of disk space for its internal needs.
>
> Ah OK, that computes. So i'll go with reiserfs on that big one (11 GB
> for internal stuff is too much i have to admit).

If I remember well, you can adjust this value in the code.

-- 
Üdvözlettel -- Mit freundlichen Grüssen,
Marcel Hilzinger

Re: journal size reiserfs vs reiser4

[Lexington Luthor]

Thomas Kuther wrote:
> Ah OK, that computes. So i'll go with reiserfs on that big one (11 GB
> for internal stuff is too much i have to admit).
> 
> Thanks!
> Tom

Other filesystems will also consume space (most of them, more so than 
reiserfs or reiser4), they will just allocate it incrementally with the 
data. The metadata handling in reiser4 is designed differently, so it 
allocated during mkfs.

Ext3 will use more space than reiser4 for the same data. reiserfs with 
tail packing will use the least space (of all the filesystems in linux), 
but will be slower than reiser4.

I would suggest reiser4 if speed is important, or XFS if data safety is 
important (since r4 is still experimental). Both of them will use around 
5-8% of the disk (depending on the number of files etc.), which is less 
than most filesystems.

LL

Re: journal size reiserfs vs reiser4

[Thomas Kuther]

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

On Thu, 1 Sep 2005 15:13:36 +0200
Marcel Hilzinger <marcel@hilzinger.hu> wrote:

> Am Donnerstag, 1. September 2005 15:05 schrieb Thomas Kuther:
> > On Thu, 01 Sep 2005 16:53:32 +0400
> >
> > "Vladimir V. Saveliev" <vs@namesys.com> wrote:
> > > Hello
> > >
> [...]
> > >
> > > reiser4 reserves 5% of disk space for its internal needs.
> >
> > Ah OK, that computes. So i'll go with reiserfs on that big one (11
> > GB for internal stuff is too much i have to admit).
> 
> If I remember well, you can adjust this value in the code.
> 
> -- 
> Üdvözlettel -- Mit freundlichen Grüssen,
> Marcel Hilzinger
> 

aha! OK. now the question would be: what is a good number for reiser4
to work properly. how much does it need from a 233GB disk? or are the
5% chosen 'cause it's the "healthy" value?

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

Re: journal size reiserfs vs reiser4

[Thomas Kuther]

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

On Thu, 01 Sep 2005 14:13:43 +0100
Lexington Luthor <lexington.luthor@gmail.com> wrote:

> Thomas Kuther wrote:
> > Ah OK, that computes. So i'll go with reiserfs on that big one (11
> > GB for internal stuff is too much i have to admit).
> > 
> > Thanks!
> > Tom
> 
> Other filesystems will also consume space (most of them, more so than 
> reiserfs or reiser4), they will just allocate it incrementally with
> the data. The metadata handling in reiser4 is designed differently,
> so it allocated during mkfs.
> 
> Ext3 will use more space than reiser4 for the same data. reiserfs
> with tail packing will use the least space (of all the filesystems in
> linux), but will be slower than reiser4.
> 
> I would suggest reiser4 if speed is important, or XFS if data safety
> is important (since r4 is still experimental). Both of them will use
> around 5-8% of the disk (depending on the number of files etc.),
> which is less than most filesystems.
> 
> LL
> 

Interesting! OK safty is important on the stuff on that disk.. anyways
reiser4 has been rocksolid on my system. even the system is completely
backed up for that reason that reiser4 is still "experimental". So
maybe XFS would be the best way to go...never dealed with it so far.
Anyways those files haven't to be accessed that fast.. and reiserfs
with tail is what i currently run on that disk. i'll keep that then i
guess :)

Thanks for the answer(s)

Regards!
Tom

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

Re: journal size reiserfs vs reiser4

[Vladimir V. Saveliev]

Hello

Peter Staubach wrote:
> 
>>> reiser4 reserves 5% of disk space for its internal needs.
>>>
> 
> 5% of today's big disks seems a little excessive.  Does reiser4 really need
> that much space or would less also suffice without compromising
> performance?
> 
No. of course.

reiser4 should be more careful about calculation of reserved space.

> Is there research available which makes up the basis for the 5% number?

I guess there was some discussion of this problem at the beginning of reiser4.
The solution, however, looks like nobody was able to come up with something reasonable.

Re: journal size reiserfs vs reiser4

[michael chang]

On 9/1/05, Thomas Kuther <gimpel@sonnenkinder.org> wrote:
> On Thu, 1 Sep 2005 15:13:36 +0200
> Marcel Hilzinger <marcel@hilzinger.hu> wrote:
> 
> > Am Donnerstag, 1. September 2005 15:05 schrieb Thomas Kuther:
> > > On Thu, 01 Sep 2005 16:53:32 +0400
> > >
> > > "Vladimir V. Saveliev" <vs@namesys.com> wrote:
> > > > reiser4 reserves 5% of disk space for its internal needs.
> > >
> > > Ah OK, that computes. So i'll go with reiserfs on that big one (11
> > > GB for internal stuff is too much i have to admit).
> >
> > If I remember well, you can adjust this value in the code.
> >
> aha! OK. now the question would be: what is a good number for reiser4
> to work properly. how much does it need from a 233GB disk? or are the
> 5% chosen 'cause it's the "healthy" value?
> 

I'd assume it depends on the way the FS is used; sort of like how you
assign the max number of inodes you can have on ext2/3.  I could be
wrong.

-- 
~Mike
 - Just my two cents
 - No man is an island, and no man is unable.

Re: journal size reiserfs vs reiser4

[Hans Reiser]

Peter Staubach wrote:

>
>>> reiser4 reserves 5% of disk space for its internal needs.
>>>
>
> 5% of today's big disks seems a little excessive.  Does reiser4 really
> need
> that much space or would less also suffice without compromising
> performance?
>
> Is there research available which makes up the basis for the 5% number?
>
>    Thanx...
>
>       ps
>
>
Research for filesystems generally says that as you get more than 85%
full the performance goes down, by a lot as you get close to 100%.  5%
is probably too little rather than too much.

Re: journal size reiserfs vs reiser4

[Peter Staubach]

Hans Reiser wrote:

>Research for filesystems generally says that as you get more than 85%
>full the performance goes down, by a lot as you get close to 100%.  5%
>is probably too little rather than too much.
>  
>

Wow.  What is all that space used for?  Other journalling file systems that
I have seen have limited things like journals to a much smaller space,
expressed in megabytes, and a much smaller number than thought originally.
The bigger journals just didn't end up adding to the performance measurably
and were just considered to be a waste of space that could be used more
usefully.

    Thanx...

       ps

Re: journal size reiserfs vs reiser4

[Marcel Hilzinger]

Am Donnerstag, 1. September 2005 18:06 schrieb Peter Staubach:
> Hans Reiser wrote:
> >Research for filesystems generally says that as you get more than 85%
> >full the performance goes down, by a lot as you get close to 100%.  5%
> >is probably too little rather than too much.
>
> Wow.  What is all that space used for?  Other journalling file systems that
> I have seen have limited things like journals to a much smaller space,
> expressed in megabytes, and a much smaller number than thought originally.
> The bigger journals just didn't end up adding to the performance measurably
> and were just considered to be a waste of space that could be used more
> usefully.
It's almost not for the journal.

AND

If you have a lot of small files, reiser4 manages space much better than every 
other filesystems. So the space you mean to loose with this 5% reiser4 gives 
it back with better packaging, eg:

kernel 2.6.12 extracted: 
with reiser4 ~ 200 MB
with ext3/reiserfs ~ 230 MB


-- 
Üdvözlettel -- Mit freundlichen Grüssen,
Marcel Hilzinger

Re: journal size reiserfs vs reiser4

[David Masover]

Peter Staubach wrote:
> Hans Reiser wrote:
> 
>> Research for filesystems generally says that as you get more than 85%
>> full the performance goes down, by a lot as you get close to 100%.  5%
>> is probably too little rather than too much.
>>  
>>
> 
> Wow.  What is all that space used for?  Other journalling file systems that
> I have seen have limited things like journals to a much smaller space,

I thought that it wasn't just for the journal, but rather, for the 
journal, metadata, and to make things saner when you fill up your drive.

Because of lazy allocation and the way things are packed, for a given 
write on an almost-full disk, the FS doesn't know at the time your 
write(2) call returns whether or not it succeeded or ran out of space. 
So, you want to have somewhat more space available than you have RAM.

But, like the decision to keep bitmaps locked in RAM, it seems very much 
overkill, and should definitely be tunable, at least.  Terabytes aren't 
just for the enterprise anymore.

Re: journal size reiserfs vs reiser4

[Hans Reiser]

David Masover wrote:

> Peter Staubach wrote:
>
>> Hans Reiser wrote:
>>
>>> Research for filesystems generally says that as you get more than 85%
>>> full the performance goes down, by a lot as you get close to 100%.  5%
>>> is probably too little rather than too much.
>>>  
>>>
>>
>> Wow.  What is all that space used for?  Other journalling file
>> systems that
>> I have seen have limited things like journals to a much smaller space,
>
BSD FFS has a 10% limit unless you are root.  They are correct to do so.

Re: journal size reiserfs vs reiser4

[Peter Staubach]

Hans Reiser wrote:

>>>>        
>>>>
>>>Wow.  What is all that space used for?  Other journalling file
>>>systems that
>>>I have seen have limited things like journals to a much smaller space,
>>>      
>>>
>BSD FFS has a 10% limit unless you are root.  They are correct to do so.
>

Yes, they reserve that space so that their algorithms to choose blocks from
the various cylinder groups can continue to choose blocks in decent 
locations.
BSD FFS doesn't journal though.

The SunOS UFS does journal metadata and retains the same 10% limit.  It was
discovered that the journal didn't need to be very big in order to maximize
performance though.  A very small log would do as well as a very large log.

It would be interesting to pick a benchmark which represents some market
that usually deploys reiersfs and then experiment with various aspects of
the file system, including the reserve space.  It is easy to do, mostly
just time consuming and requires a fair amount of resources.

       ps

Re: journal size reiserfs vs reiser4

[Hans Reiser]

Peter Staubach wrote:

> Hans Reiser wrote:
>
>>>>>       
>>>>
>>>> Wow.  What is all that space used for?  Other journalling file
>>>> systems that
>>>> I have seen have limited things like journals to a much smaller space,
>>>>     
>>>
>> BSD FFS has a 10% limit unless you are root.  They are correct to do so.
>>
>
> Yes, they reserve that space so that their algorithms to choose blocks
> from
> the various cylinder groups can continue to choose blocks in decent
> locations.
> BSD FFS doesn't journal though.
>
> The SunOS UFS does journal metadata and retains the same 10% limit. 
> It was
> discovered that the journal didn't need to be very big in order to
> maximize
> performance though.  A very small log would do as well as a very large
> log.

Journaling, and reserving space for good allocation, are totally
different concerns, I don't understand why you guys are conflating them.

>
> It would be interesting to pick a benchmark which represents some market
> that usually deploys reiersfs and then experiment with various aspects of
> the file system, including the reserve space.  It is easy to do, mostly
> just time consuming and requires a fair amount of resources.
>
>       ps
>
>

Re: journal size reiserfs vs reiser4

[Peter Staubach]

Hans Reiser wrote:

>
>Journaling, and reserving space for good allocation, are totally
>different concerns, I don't understand why you guys are conflating them.
>

Agreed, that journaling and reserving space for good allocation are 
separate,
except that often the space for the journal is reserved.  Only being able to
see one measurement that indicates space reserved from the file system makes
it confusing.

    Thanx...

       ps

Re: journal size reiserfs vs reiser4

[Hans Reiser]

Peter Staubach wrote:

> Hans Reiser wrote:
>
>> Research for filesystems generally says that as you get more than 85%
>> full the performance goes down, by a lot as you get close to 100%.  5%
>> is probably too little rather than too much.
>>  
>>
>
> Wow.  What is all that space used for?

Emptiness.  So that when you need a free block you don't go to the end
of the disk drive to get it.  Not for journals, metadata, just
emptiness.  Bigger journals are a completely different topic.

>   Other journalling file systems that
> I have seen have limited things like journals to a much smaller space,
> expressed in megabytes, and a much smaller number than thought
> originally.
> The bigger journals just didn't end up adding to the performance
> measurably
> and were just considered to be a waste of space that could be used more
> usefully.
>
>    Thanx...
>
>       ps
>
>

Re: journal size reiserfs vs reiser4

[michael chang]

On 9/1/05, Peter Staubach <staubach@redhat.com> wrote:
> Hans Reiser wrote:
> 
> >Research for filesystems generally says that as you get more than 85%
> >full the performance goes down, by a lot as you get close to 100%.  5%
> >is probably too little rather than too much.
> >
> 
> Wow.  What is all that space used for?  Other journalling file systems that
> I have seen have limited things like journals to a much smaller space,
> expressed in megabytes, and a much smaller number than thought originally.
> The bigger journals just didn't end up adding to the performance measurably
> and were just considered to be a waste of space that could be used more
> usefully.
> 

Block-allocation efficiency.  Mainly to prevent super extreme
fragmentation of even the smallest files, and to give enough room to
do something that looks like repacking/defragmentation.

If you want to do repacking w/o 15-25%+ free space, then you're pretty
much looking at the kind of algorithm found in Windows 9x
(semi-offline defragment, and arrange blocks one at a time); online
repacking is painful without much free space (often you have to
repeatedly re consolidate the free space, which kinda messes things
up).

Of course, for me personally, Reiser4 will be about 20 times more
useful if it's a 40 GB disk and I can fill it up to 99% and defragment
it completely within 12 hours or so, with maybe 10-20 files which are
275 MBs in size.  Win XP and sure NTFS couldn't do it, even with
proprietary defragmenters...

-- 
~Mike
 - Just my two cents
 - No man is an island, and no man is unable.

Re: journal size reiserfs vs reiser4

[Vladimir V. Saveliev]

Hello

michael chang wrote:
> On 9/1/05, Peter Staubach <staubach@redhat.com> wrote:
>>Hans Reiser wrote:
>>
>>>Research for filesystems generally says that as you get more than 85%
>>>full the performance goes down, by a lot as you get close to 100%.  5%
>>>is probably too little rather than too much.
>>>
>>Wow.  What is all that space used for? 

Reiser4 allocates log records dynamically. So it has to allocate some disk space even when it is about to remove a file.
Reserved space is used when allocation is required to preform removal operation.
This allows to avoid returning ENOSPC on operations which are usually used to free disk space.

 Other journalling file systems that
>>I have seen have limited things like journals to a much smaller space,
>>expressed in megabytes, and a much smaller number than thought originally.
>>The bigger journals just didn't end up adding to the performance measurably
>>and were just considered to be a waste of space that could be used more
>>usefully.
>>
> 
> Block-allocation efficiency.  Mainly to prevent super extreme
> fragmentation of even the smallest files, and to give enough room to
> do something that looks like repacking/defragmentation.
> 
> If you want to do repacking w/o 15-25%+ free space, then you're pretty
> much looking at the kind of algorithm found in Windows 9x
> (semi-offline defragment, and arrange blocks one at a time); online
> repacking is painful without much free space (often you have to
> repeatedly re consolidate the free space, which kinda messes things
> up).
> 
> Of course, for me personally, Reiser4 will be about 20 times more
> useful if it's a 40 GB disk and I can fill it up to 99% and defragment
> it completely within 12 hours or so, with maybe 10-20 files which are
> 275 MBs in size.  Win XP and sure NTFS couldn't do it, even with
> proprietary defragmenters...
> 

Re: journal size reiserfs vs reiser4

[Hans Reiser]

Vladimir V. Saveliev wrote:

>Hello
>
>michael chang wrote:
>  
>
>>On 9/1/05, Peter Staubach <staubach@redhat.com> wrote:
>>    
>>
>>>Hans Reiser wrote:
>>>
>>>      
>>>
>>>>Research for filesystems generally says that as you get more than 85%
>>>>full the performance goes down, by a lot as you get close to 100%.  5%
>>>>is probably too little rather than too much.
>>>>
>>>>        
>>>>
>>>Wow.  What is all that space used for? 
>>>      
>>>
>
>Reiser4 allocates log records dynamically. So it has to allocate some disk space even when it is about to remove a file.
>Reserved space is used when allocation is required to preform removal operation.
>This allows to avoid returning ENOSPC on operations which are usually used to free disk space.
>  
>
It could probably be a lot less than 5%, 2% is more than enough I would
guess, but we also need to reserve space to get good performance.

Re: journal size reiserfs vs reiser4

[PFC]

> It could probably be a lot less than 5%, 2% is more than enough I would
> guess, but we also need to reserve space to get good performance.

	I'm more than happy to lose 3 GB on my 60 gb /  5400 rpm crap laptop  
drive and have reiser4 transform it into something that feels more like a  
big f*king raptor. Everytime I boot into Windows I feel the burning pain  
of this crap drive combined with the cancer of NTFS. Uh-oh this file takes  
long to load OH CRAP it's fragmented in 20000 bits (my personal record !).  
Gee. Gotta. Defrag. Again.
	Note that on your average Linux system with a zillion of small files the  
efficient reiser4 packing will save a lot of space.
	Un-tar the freedb database on a NTFS (or EXT3) partition and witness how  
your machine dies, then stop complaining about reiser4 eating 5% of your  
space dammit.

Re: journal size reiserfs vs reiser4

[michael chang]

On 9/2/05, PFC <lists@boutiquenumerique.com> wrote:
> 
> > It could probably be a lot less than 5%, 2% is more than enough I would
> > guess, but we also need to reserve space to get good performance.

Maybe 2% would be necessary for the delete operations -- the rest is
to prevent fragmentation (like I said) and various other tidbits. 
Simply, if df reports more than 85% full, generally people believe
that performance will go down (that space is unused, regardless). 
It'd be interesting for an optimized read-write fileystem with
repacker (not necessarily online) that still has excellent performance
even at 95-97% full.

>         I'm more than happy to lose 3 GB on my 60 gb /  5400 rpm crap laptop
> drive and have reiser4 transform it into something that feels more like a
> big f*king raptor. Everytime I boot into Windows I feel the burning pain
> of this crap drive combined with the cancer of NTFS. Uh-oh this file takes

Try emptying your prefetch, and see if that helps... defragmentation
won't work unless you have enough contiguous space for all of your
fragmented files.  Totally unlikely.  And Windows takes *forever* to
repack free space, and even then it doesn't do so solidly (if you have
barely enough space to defragment e.g. one file).

> long to load OH CRAP it's fragmented in 20000 bits (my personal record !).
> Gee. Gotta. Defrag. Again.

I've defragmented for 24-48 hours straight (repetated cycles) in
proprietary and built-in defragmenters -- and still it wouldn't
defragment even one or two of my largest, and most fragmented files (I
believe it's about 275 MB video file in 30000-40000 pieces).  Still'd
love to boot Windows off a Reiser4 partition...

>         Note that on your average Linux system with a zillion of small files the
> efficient reiser4 packing will save a lot of space.

Yes.

>         Un-tar the freedb database on a NTFS (or EXT3) partition and witness how
> your machine dies, then stop complaining about reiser4 eating 5% of your
> space dammit.

As soon as I can install root reiser4 and get repacker/resizer -- I'm
patient though. ^^

-- 
~Mike
 - Just my two cents
 - No man is an island, and no man is unable.

Re: journal size reiserfs vs reiser4

[Łukasz Mierzwa]

Dnia Fri, 02 Sep 2005 09:19:55 +0200, Hans Reiser <reiser@namesys.com> napisa³:

> It could probably be a lot less than 5%, 2% is more than enough I would
> guess, but we also need to reserve space to get good performance.
>

Maybe You can make it an mkfs.reiser4 option, set 5% to default so it won't change anything to 99% of people using reiser4 but will make that 1% that want some other value happy.

Re: journal size reiserfs vs reiser4

[Gregory Maxwell]

On 9/2/05, £ukasz Mierzwa <prymitive@pcserwis.net> wrote:
> Dnia Fri, 02 Sep 2005 09:19:55 +0200, Hans Reiser <reiser@namesys.com> napisa³:
> > It could probably be a lot less than 5%, 2% is more than enough I would
> > guess, but we also need to reserve space to get good performance.
> Maybe You can make it an mkfs.reiser4 option, set 5% to default so it won't change anything to 99% of people using reiser4 but will make that 1% that want some other value happy.

What would be really nice would be to have two options, a reserved
amount, and a root reserved amount at mkfs time. The behaviour of the
ext2/3 filesystem allows you to reserve some portion of the disk for
root use. This prevents various unpleasant system failure modes when a
user task goes nuts and fills the disk. It would be even more nice if
rather than root/nonroot if it could be controlled by a
capability/selinux context so you could make it so syslog can't write
into that safe buffer..

But it's kinda moot at this point, mainline inclusion must be the
highest priority right now.

Re: journal size reiserfs vs reiser4

[Matt Stegman]

Just to add another voice to the cachophony, I would like to be able to
select the amount.  At any time, not just at mkfs time.  For example,
ext2's reserved blocks are set by default to 5%, but I can use tune2fs to
change that to 33% or 0% or whatever makes me happy.

The point is that sometimes I care more about performance than space usage
(hard disks are cheap, blah blah) and sometimes I wish to use 100% of my
disk, even knowing that it means high fragmentation.

As far as repacking goes, I believe xfs_fsr refuses to defrag files if too
little space is free.  If it's too hard to program a repacker to operate
efficiently with only a few megabytes free, simply program it to exit with
error when less than 5% disk is free.

-- 
Matt Stegman

On Fri, 2 Sep 2005, Hans Reiser wrote:

> It could probably be a lot less than 5%, 2% is more than enough I would
> guess, but we also need to reserve space to get good performance.
>
>

Re: journal size reiserfs vs reiser4

[Sander]

Hans Reiser wrote (ao):
> Research for filesystems generally says that as you get more than 85%
> full the performance goes down, by a lot as you get close to 100%.  5%
> is probably too little rather than too much.

Does this mean that if my reiser4 filesystem is 90% full, it can be
considered 85% full wrt performance because of the 5% reservation?

	Sander

-- 
Humilis IT Services and Solutions
http://www.humilis.net

Re: journal size reiserfs vs reiser4

[Pierre Etchemaïté]

Le Sat, 3 Sep 2005 12:08:46 +0200, Sander <sander@humilis.net> a écrit :

> Does this mean that if my reiser4 filesystem is 90% full, it can be
> considered 85% full wrt performance because of the 5% reservation?

0.9 * 0.95 = 0.855

so it should be 85.5% full if you consider its real physical capacity.

(slight difference, only pointing out a common mistake people do when
percentages are involved...)

Re: journal size reiserfs vs reiser4

[Hans Reiser]

Sander wrote:

>Hans Reiser wrote (ao):
>  
>
>>Research for filesystems generally says that as you get more than 85%
>>full the performance goes down, by a lot as you get close to 100%.  5%
>>is probably too little rather than too much.
>>    
>>
>
>Does this mean that if my reiser4 filesystem is 90% full, it can be
>considered 85% full wrt performance because of the 5% reservation?
>
>	Sander
>
>  
>
yes, approximately.

Re: journal size reiserfs vs reiser4

[michael chang]

On 9/2/05, Matt Stegman <matts@ksu.edu> wrote:
> As far as repacking goes, I believe xfs_fsr refuses to defrag files if too
> little space is free.  If it's too hard to program a repacker to operate
> efficiently with only a few megabytes free, simply program it to exit with
> error when less than 5% disk is free.

I'd rather leave the repacker running inefficiently if it'll mean
it'll run more efficiently in the future.  [I believe Windows 9x's
repacker could get away with having just one free cluster if
necessary, although it'd have been painfully slow.]  Sometimes, I
can't clear off files unless I archive them, but they won't archive
unless they read fast enough (and fragmentation slows them down just
enough so they won't read fast enough - due to weird time constaints
that are built into the program that shouldn't be there).

It's possible to defragment tons of really small files with less than
5%, and that number changes with the size of the HD (you can't use an
arbirtrary number like 15%, like Windows XP, because that varies
heavily -- even if you had 50% free, if there were no two continous
free clusters, you couldn't defragment with the defragmenter in XP --
I don't want this kind of behaviour as the only way to do repack
things in case I end up in a weird spot.)

That said, I'd be half-satisfied if a repacker is released months or
years earlier because it doesn't efficiently handle weird cases (so
long as it remembers to try and repack free space too).  As for the 5%
error; a warning is safer.  Either that, or put in a force option to
get around the "error".

-- 
~Mike
 - Just my two cents
 - No man is an island, and no man is unable.

Re: journal size reiserfs vs reiser4

[David Masover]

michael chang wrote:
> On 9/2/05, Matt Stegman <matts@ksu.edu> wrote:

> That said, I'd be half-satisfied if a repacker is released months or
> years earlier because it doesn't efficiently handle weird cases (so
> long as it remembers to try and repack free space too).  As for the 5%
> error; a warning is safer.  Either that, or put in a force option to
> get around the "error".

A mount option specifying the amount of space to reserve?

You probably don't want to disable the limit altogether.  Some people
might go the other way, forcing at least 15-25% of the disk to be free
for performance reasons.  I think the mount option is safest, and
certainly safer than trying to do this per-process.

Re: journal size reiserfs vs reiser4

[Hans Reiser]

David Masover wrote:

>michael chang wrote:
>  
>
>>On 9/2/05, Matt Stegman <matts@ksu.edu> wrote:
>>    
>>
>
>  
>
>>That said, I'd be half-satisfied if a repacker is released months or
>>years earlier because it doesn't efficiently handle weird cases (so
>>long as it remembers to try and repack free space too).  As for the 5%
>>error; a warning is safer.  Either that, or put in a force option to
>>get around the "error".
>>    
>>
>
>A mount option specifying the amount of space to reserve?
>
>You probably don't want to disable the limit altogether.  Some people
>might go the other way, forcing at least 15-25% of the disk to be free
>for performance reasons.  I think the mount option is safest, and
>certainly safer than trying to do this per-process.
>
>
>
>  
>
This is a bit arrogant, but I believe that a user that does not know how
to recompile the kernel with the #define changed is not sophisticated
enough to know how much he is going to hurt his performance by going
from 95% to 99% space used, and a user who does not want to bother with
recompiling is not going to study the topic enough to realize he is
making a mistake 80% of the time.  It is important to know when
designing a product when your users intuitions are going to be wrong
80%of the time, and while one should always be slow to reach such a
conclusion, I think this is such a case.

Hans

Re: journal size reiserfs vs reiser4

[Clemens Eisserer]

Well, it sounds a bit like a microsoft manager explaining why XP-Home
has no terminal server features ;-)

I think an mkfs-option would be best, with a warning if the value
given by the user is nonsence (3-8% ok?).
On the contrary a 500GB hard drive with normal files on it would not
benefit too much just because 25GB are free?

lg Clemens

> This is a bit arrogant, but I believe that a user that does not know how
> to recompile the kernel with the #define changed is not sophisticated
> enough to know how much he is going to hurt his performance by going
> from 95% to 99% space used, and a user who does not want to bother with
> recompiling is not going to study the topic enough to realize he is
> making a mistake 80% of the time.  It is important to know when
> designing a product when your users intuitions are going to be wrong
> 80%of the time, and while one should always be slow to reach such a
> conclusion, I think this is such a case.

Re: journal size reiserfs vs reiser4

[David Masover]

Clemens Eisserer wrote:
> Well, it sounds a bit like a microsoft manager explaining why XP-Home
> has no terminal server features ;-)
> 
> I think an mkfs-option would be best, with a warning if the value
> given by the user is nonsence (3-8% ok?).

Is there a reason we need to specify this at mkfs time?  What about a 
mount option?

It seems that if you could do this in the kernel source, you could 
certainly do it at mount-time, per-fs.  In other words, it seems that 
it's not something which needs to be specified in the FS format itself.

>>This is a bit arrogant, but I believe that a user that does not know how
>>to recompile the kernel with the #define changed is not sophisticated
>>enough to know how much he is going to hurt his performance by going
>>from 95% to 99% space used, and a user who does not want to bother with
>>recompiling is not going to study the topic enough to realize he is
>>making a mistake 80% of the time.  It is important to know when
>>designing a product when your users intuitions are going to be wrong
>>80%of the time, and while one should always be slow to reach such a
>>conclusion, I think this is such a case.

And yet, there are still plenty of options in the kernel, in mount 
options and in menuconfig, which are dangerous and almost never right.

Re: journal size reiserfs vs reiser4

[michael chang]

On 9/3/05, michael chang <thenewme91@gmail.com> wrote:
> long as it remembers to try and repack free space too).  As for the 5%
> error; a warning is safer.  Either that, or put in a force option to
> get around the "error".

To clearify, I was referring to being able to bypass a potential
warning on less than 5% free ON TOP OF THE 5% THAT IS RESERVED BY
REISER4 in the REPACKER.

Of course, the 5% already reserved, I believe, is important -
reserving 7.5 or 10% wouldn't kill anyone either, IMO, unless they're
on an embedded system (but that has it's own issues entirely anyhoo).

-- 
~Mike
 - Just my two cents
 - No man is an island, and no man is unable.

Re: journal size reiserfs vs reiser4

[michael chang]

On 9/4/05, David Masover <ninja@slaphack.com> wrote:
> Clemens Eisserer wrote:
> > Well, it sounds a bit like a microsoft manager explaining why XP-Home
> > has no terminal server features ;-)
> >
> > I think an mkfs-option would be best, with a warning if the value
> > given by the user is nonsence (3-8% ok?).
> 
> Is there a reason we need to specify this at mkfs time?  What about a
> mount option?

When maybe we'd need to change the metadata.  Even in ext2/3 you can
only modify this by "tuning" the fs.

> >>This is a bit arrogant, but I believe that a user that does not know how
> >>to recompile the kernel with the #define changed is not sophisticated
> >>enough to know how much he is going to hurt his performance by going
> >>from 95% to 99% space used, and a user who does not want to bother with
> >>recompiling is not going to study the topic enough to realize he is
> >>making a mistake 80% of the time.  It is important to know when
> >>designing a product when your users intuitions are going to be wrong
> >>80%of the time, and while one should always be slow to reach such a
> >>conclusion, I think this is such a case.

I agree here, and anyone who disagrees is either weird, or lacks
common sense.  The arrogance is just part of your personality, Hans,
it's nothing to worry about.  We know not to take it as an insult. :P

-- 
~Mike
 - Just my two cents
 - No man is an island, and no man is unable.

Re: journal size reiserfs vs reiser4

[David Masover]

michael chang wrote:
> On 9/4/05, David Masover <ninja@slaphack.com> wrote:
> 
>>Clemens Eisserer wrote:
>>
>>>Well, it sounds a bit like a microsoft manager explaining why XP-Home
>>>has no terminal server features ;-)
>>>
>>>I think an mkfs-option would be best, with a warning if the value
>>>given by the user is nonsence (3-8% ok?).
>>
>>Is there a reason we need to specify this at mkfs time?  What about a
>>mount option?
> 
> 
> When maybe we'd need to change the metadata.  Even in ext2/3 you can
> only modify this by "tuning" the fs.
> 
> 
>>>>This is a bit arrogant, but I believe that a user that does not know how
>>>>to recompile the kernel with the #define changed is not sophisticated
>>>>enough to know how much he is going to hurt his performance by going
>>>
>>>>from 95% to 99% space used, and a user who does not want to bother with
>>>
>>>>recompiling is not going to study the topic enough to realize he is
>>>>making a mistake 80% of the time.  It is important to know when
>>>>designing a product when your users intuitions are going to be wrong
>>>>80%of the time, and while one should always be slow to reach such a
>>>>conclusion, I think this is such a case.
> 
> 
> I agree here, and anyone who disagrees is either weird, or lacks
> common sense.

That's not an argument.  As we learned in Philosophy class, that is 
called "begging the question."

I'm betting that a user who wants to tune this and understands what it 
means won't want to have to recompile just to test out a new setting, 
and a user who doesn't understand the mistake they are making probably 
won't be able to change a menuconfig option, a mount option, or a tunefs 
option by themself anyway.  And, if they do, they should realize that it 
can be dangerous and/or stupid to tweak these things -- after all, some 
options still in menuconfig can cause massive fs corruption, and say so.

And, anyone who disagrees with me must lack common sense :P

Re: journal size reiserfs vs reiser4

[michael chang]

On 9/5/05, David Masover <ninja@slaphack.com> wrote:
> I'm betting that a user who wants to tune this and understands what it
> means won't want to have to recompile just to test out a new setting,

Maybe because s/he is in a special situation? I suppose...

-- 
~Mike
 - Just my two cents
 - No man is an island, and no man is unable.

Re: journal size reiserfs vs reiser4

[Tom Vier]

On Sat, Sep 03, 2005 at 08:48:01PM -0700, Hans Reiser wrote:
> This is a bit arrogant, but I believe that a user that does not know how
> to recompile the kernel with the #define changed is not sophisticated

I think it's pretty inconvenient to have to change that and rebuild the
kernel (possibly voiding a vendor's warrenty) just to change the reserve %.
ext2/3 has always had it tunable. As long as a reasonable % is chosen, few
will bother to change it. What if your file server is almost full, but you
can't get funding for more drives for a couple months? You have to rebuild
your kernel if you just want to use another 2%?

Rebuilding a kernel is no big deal for me, but it is for others, and not
just because of lack of ability. I'm sure there are situations where you
can't just plop in a new kernel (company security policies, support
contracts, etc), no matter how easy it is to build.


My vote: put the reserve % in the superblock (if it isn't already) and
give mkfs a sane default.

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

Re: journal size reiserfs vs reiser4

[michael chang]

On 9/6/05, Tom Vier <tmv@comcast.net> wrote:
> On Sat, Sep 03, 2005 at 08:48:01PM -0700, Hans Reiser wrote:
> > This is a bit arrogant, but I believe that a user that does not know how
> > to recompile the kernel with the #define changed is not sophisticated
> 
> I think it's pretty inconvenient to have to change that and rebuild the
> kernel (possibly voiding a vendor's warrenty) just to change the reserve %.
> ext2/3 has always had it tunable. As long as a reasonable % is chosen, few
> will bother to change it. What if your file server is almost full, but you
> can't get funding for more drives for a couple months? You have to rebuild
> your kernel if you just want to use another 2%?
> 
> Rebuilding a kernel is no big deal for me, but it is for others, and not
> just because of lack of ability. I'm sure there are situations where you
> can't just plop in a new kernel (company security policies, support
> contracts, etc), no matter how easy it is to build.
> 
> 
> My vote: put the reserve % in the superblock (if it isn't already) and
> give mkfs a sane default.
> 

Okay, this sounds sane, but at the same time, from a implementational
point of view, how do you tell which blocks are reserved and which
arent?

-- 
~Mike
 - Just my two cents
 - No man is an island, and no man is unable.

Re: journal size reiserfs vs reiser4

[Gregory Maxwell]

On 9/6/05, Tom Vier <tmv@comcast.net> wrote:
> My vote: put the reserve % in the superblock (if it isn't already) and
> give mkfs a sane default.

Looking at the code it appears it would be easier to make it a mount
option that defaults to 5%. Would that work okay for you?

Re: journal size reiserfs vs reiser4

[michael chang]

On 9/6/05, Gregory Maxwell <gmaxwell@gmail.com> wrote:
> On 9/6/05, Tom Vier <tmv@comcast.net> wrote:
> > My vote: put the reserve % in the superblock (if it isn't already) and
> > give mkfs a sane default.
> 
> Looking at the code it appears it would be easier to make it a mount
> option that defaults to 5%. Would that work okay for you?
> 

I dunno about him, but I think it's okay -- provided that it doesn't
screw up too bad.  That said, more people are likely to fiddle with
/etc/fstab than with fstune options... but that's an opinion.  Either
way, it would likely be good to mark it as a potentially dangerous or
performance-deterring thing.  And you don't want to reduce it so much
that there's no room for metadata or space to write in order to delete
if full.

-- 
~Mike
 - Just my two cents
 - No man is an island, and no man is unable.

Re: journal size reiserfs vs reiser4

[David Masover]

michael chang wrote:

> Okay, this sounds sane, but at the same time, from a implementational
> point of view, how do you tell which blocks are reserved and which
> arent?

I thought it wasn't specific blocks, but rather a certain number of
blocks (any blocks) which must be free in order for any write to
succeed.  Which is why it makes more sense to me as a mount option.

Re: journal size reiserfs vs reiser4

[michael chang]

On 9/6/05, David Masover <ninja@slaphack.com> wrote:
> michael chang wrote:
> 
> > Okay, this sounds sane, but at the same time, from a implementational
> > point of view, how do you tell which blocks are reserved and which
> > arent?
> 
> I thought it wasn't specific blocks, but rather a certain number of
> blocks (any blocks) which must be free in order for any write to
> succeed.  Which is why it makes more sense to me as a mount option.
> 

Oh okay then.  That sounds better - it's not like NTFS's MFT area
designation (very annoying).  Of course, we'd all like it better if
this space is contiguous, but anywhere is fine, so long as the
benefits are retained, I guess.  (Besides, if the space *isn't*
contiguous, logically, it _should_ be possible to make it
semi-contigous with the repacker, provided enough space (hopefully
this requirement will be very low) exists to repack in the first
place.)

-- 
~Mike
 - Just my two cents
 - No man is an island, and no man is unable.

Re: journal size reiserfs vs reiser4

[David Masover]

michael chang wrote:
> On 9/6/05, David Masover <ninja@slaphack.com> wrote:
> 
>>michael chang wrote:
>>
>>
>>>Okay, this sounds sane, but at the same time, from a implementational
>>>point of view, how do you tell which blocks are reserved and which
>>>arent?
>>
>>I thought it wasn't specific blocks, but rather a certain number of
>>blocks (any blocks) which must be free in order for any write to
>>succeed.  Which is why it makes more sense to me as a mount option.
>>
> 
> 
> Oh okay then.  That sounds better - it's not like NTFS's MFT area
> designation (very annoying).  Of course, we'd all like it better if
> this space is contiguous, but anywhere is fine, so long as the
> benefits are retained, I guess.  (Besides, if the space *isn't*
> contiguous, logically, it _should_ be possible to make it
> semi-contigous with the repacker, provided enough space (hopefully
> this requirement will be very low) exists to repack in the first
> place.)

Which is already somewhat guarenteed by the reserved free space.

Re: journal size reiserfs vs reiser4

[Hans Reiser]

Guys, I am sorry, but I just don't think this issue is a priority
compared to other issues.  Sorry, too much else going on, honestly.

Re: journal size reiserfs vs reiser4

[Gregory Maxwell]

On 9/6/05, Hans Reiser <reiser@namesys.com> wrote:
> Guys, I am sorry, but I just don't think this issue is a priority
> compared to other issues.  Sorry, too much else going on, honestly.

I'd say so:

Per Andrew Morton. 

reiser4 merge status:
    Stuck.  Last time we discussed this I asked the reiser4 team to
    develop and negotiate a bullet-point list of things to be addressed. 
    Once that's agreed to, implement it and then we can merge it.  None of
    that has happened and as far as I know, all the review feedback which
    was provided was lost.

:(

Re: journal size reiserfs vs reiser4

[Tom Vier]

On Tue, Sep 06, 2005 at 04:36:33PM -0400, Gregory Maxwell wrote:
> On 9/6/05, Tom Vier <tmv@comcast.net> wrote:
> > My vote: put the reserve % in the superblock (if it isn't already) and
> > give mkfs a sane default.
> 
> Looking at the code it appears it would be easier to make it a mount
> option that defaults to 5%. Would that work okay for you?

I think that's better than a #define, but i'd still prefer something a
little more sticky than a mount option (a field in the superblock). You
might manually mount it and forget to specify it. I could certainly live
with it as a mount option, but i think putting it in the superblock is
the correct place, imho.

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

Re: journal size reiserfs vs reiser4

[michael chang]

On 9/7/05, Tom Vier <tmv@comcast.net> wrote:
> On Tue, Sep 06, 2005 at 04:36:33PM -0400, Gregory Maxwell wrote:
> > On 9/6/05, Tom Vier <tmv@comcast.net> wrote:
> > > My vote: put the reserve % in the superblock (if it isn't already) and
> > > give mkfs a sane default.
> >
> > Looking at the code it appears it would be easier to make it a mount
> > option that defaults to 5%. Would that work okay for you?
> 
> I think that's better than a #define, but i'd still prefer something a
> little more sticky than a mount option (a field in the superblock). You
> might manually mount it and forget to specify it. I could certainly live
> with it as a mount option, but i think putting it in the superblock is
> the correct place, imho.

So you can change it in the mount options, but it's stored in the
superblock (e.g. the last value used or the default)?  Would that
help?  Or do we want to go to the trouble of making a reiser4tune
program capable of changing this value in the superblock?

-- 
~Mike
 - Just my two cents
 - No man is an island, and no man is unable.

reiser4 merge status

[Hans Reiser]

Andrew, we have been working on a big patch that resolves the VFS
layering issues.  This patch should be ready to send in any day now, we
are debugging it.  We may not have been sending you a lot of emails, but
we have been working away at it.  I don't understand why you think the
review feedback was lost.

I will have Zam review the email history, develop the bullet list for
you, and send it.

Hans

Gregory Maxwell wrote:

>Per Andrew Morton. 
>
>reiser4 merge status:
>    Stuck.  Last time we discussed this I asked the reiser4 team to
>    develop and negotiate a bullet-point list of things to be addressed. 
>    Once that's agreed to, implement it and then we can merge it.  None of
>    that has happened and as far as I know, all the review feedback which
>    was provided was lost.
>
>:(
>
>
>  
>

Re: reiser4 merge status

[Andrew Morton]

Hans Reiser <reiser@namesys.com> wrote:
>
> Andrew, we have been working on a big patch that resolves the VFS
> layering issues.  This patch should be ready to send in any day now, we
> are debugging it.  We may not have been sending you a lot of emails, but
> we have been working away at it.

That's good news.

>  I don't understand why you think the
> review feedback was lost.

Because I never saw the condensed list of open issues.

> I will have Zam review the email history, develop the bullet list for
> you, and send it.

OK, thanks, it's important.  Lots of people spent time looking over and
discussing the code.  They don't want to have to a) go back and re-read
everything to remember what their concerns were and b) scratch through the
new code to find out if their concerns were addressed, and how they were
addressed.

So I'd view Zam's list as pretty important.