Re: reiser4 performance

Re: reiser4 performance

[Pysiak Satriani]

Hello David,

Monday, August 8, 2005, 9:56:36 PM, you wrote:
> What I want is the repacker, beacuse performance does steadily degrade
> on my Reiser4 systems, eventually getting worse than Reiser3, but not
> worse than VFAT -- probably because my old FAT partitions are on old,
> virus-ridden systems.
Hmm, so it seems that repacking would be a quite mandatory thing to do
once in a while. Is that what you are saying?
Kinda strange, I do not think other fss need it that bad, but running it
from cron.monthly would suffice.

How much time does repacking take? I know it takes a lot of factors, but
aproximately how much?

During repacking is the system usable, i mean: can i start repacking and
then continue hacking/writing/playing or whatever i am doing on the
computer?

-- 
Best regards,
Pysiak

Re: reiser4 performance

[Hans Reiser]

I think we should just let the current possible big sponsor take care of
the repacker sponsoring, and I will focus on making that happen.

Hns

reiser4 performance

[Hemiplegic Menehune]

Hi,

I just wanted to say thank you for putting together reiser4 :)

I just upgraded to the latest -mm kernel on my box and my jaw is on the 
floor looking at the performance of reiser4. I have previously played around 
with it on a few occasions, but I never had the chance to test it with my 
software before - it is literally 3 times as fast as reiserfs3 (which itself 
is twice as fast as ext3) - how did you guys do it? :)

The only thing reiser4 runs slower than ext3 is postgresql!

Its already as stable as any other fs on my systems and recovers better than 
most when my battery runs out. Any idea when it will make it into the stable 
2.6 kernel?

- HM

Re: reiser4 performance

[PFC]

> I just wanted to say thank you for putting together reiser4 :)

	Same here. The first filesystem ever which makes a crummy laptop drive  
look goo, and that's saying something.

Re: reiser4 performance

[Raymond A. Meijer]

On Monday 8 August 2005 13:32, Hemiplegic Menehune wrote:

> Its already as stable as any other fs on my systems and recovers
> better than most when my battery runs out. Any idea when it will make
> it into the stable 2.6 kernel?

If only it had a resizer :(

That's one of the main reasons I stopped using Reiser4 and went back to 
ReiserFS.


Ray

Re: reiser4 performance

[Ingo Bormuth]

On 2005-08-08 14:09, Raymond A. Meijer wrote:
> > Its already as stable as any other fs on my systems and recovers
> > better than most when my battery runs out. Any idea when it will make
> > it into the stable 2.6 kernel?

Yes, yes, yes. 
I had a DMA problem and the laptop froze several times on high load.
I never, ever found any fs corruption !!!
 
> If only it had a resizer :(

Yes, yes, yes.
I hear it is a matter of money. So why don't you raise a fund?
I pretty much like the concept at fundable.org.



-- 
   +--------------------------------------------------------+
   | Ingo Bormuth,  voicebox & telefax: +49-12125-10226517  |
   | GnuPG key 86326EC9 at http://ibormuth.efil.de/contact  |
   +--------------------------------------------------------+

Re: reiser4 performance

[PFC]

>> If only it had a resizer :(

	I would definitely give $25 for the repacker, which is the mandatory  
condition to get the resizer. How many people would give $25 too ? why not  
do a little fundraising ?

Re: reiser4 performance

[David Masover]

PFC wrote:
> 
>>> If only it had a resizer :(
> 
> 
>     I would definitely give $25 for the repacker, which is the 
> mandatory  condition to get the resizer. How many people would give $25 
> too ? why not  do a little fundraising ?

I would give $25 before it is done, only if it will be F/OSS.  I would 
give $25 _after_ it's done to get my own personal, proprietary copy.

Re: reiser4 performance

[michael chang]

On 8/8/05, David Masover <ninja@slaphack.com> wrote:
> PFC wrote:
> >>> If only it had a resizer :(
> >     I would definitely give $25 for the repacker, which is the
> > mandatory  condition to get the resizer. How many people would give $25
> > too ? why not  do a little fundraising ?
> I would give $25 before it is done, only if it will be F/OSS.  I would
> give $25 _after_ it's done to get my own personal, proprietary copy.

If you saw in the other e-mail... Hans said Resizer/Repacker (both or
just one or the other, I don't know...) could be done for $90k ($90
000 USD, I interpret this?).  [Plus 5% of disk drive hardware costs...
whatever that could possibly be.]

Assuming we went the Paypal route via Fundable.org and the money went
straight to a Namesys Paypal Merchant account; we'd need $ 92024.84
USD before the 2.2% and $.30 USD deduction.  Assuming that every
person donated $25 (which will obviously not be the case; some will
donate more; some might less if we have to scrounge around, which we
might) ; we'd need about 3681 people to donate.

Assuming we went third-party before Namesys, and that money went from
a third-party's Paypal account to Namesys, we'd need to charge the
fees twice... a minimum of $94095.23 USD would be required; requiring
a minimum of 3764 donators at $25 apiece.

At this rate, and considering potential insecurities with Paypal,
obviously, another method would be necessary... but the funds are
still substansial at this point; even 3600 donators at $25 apiece
[inferring that there is no cost to transfer the money to Namesys]
would be hard to find.

[ATM, I don't even have $25 myself to fund such a venture, although I
would love the product.]

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

Re: reiser4 performance

[michael chang]

On 8/8/05, michael chang <thenewme91@gmail.com> wrote:
> On 8/8/05, David Masover <ninja@slaphack.com> wrote:
> > PFC wrote:
> > >>> If only it had a resizer :(
> > >     I would definitely give $25 for the repacker, which is the
> > > mandatory  condition to get the resizer. How many people would give $25
> > > too ? why not  do a little fundraising ?
> > I would give $25 before it is done, only if it will be F/OSS.  I would
> > give $25 _after_ it's done to get my own personal, proprietary copy.

> Assuming we went the Paypal route via Fundable.org and the money went
> straight to a Namesys Paypal Merchant account; we'd need $ 92024.84
> USD before the 2.2% and $.30 USD deduction.  Assuming that every
> person donated $25 (which will obviously not be the case; some will
> donate more; some might less if we have to scrounge around, which we
> might) ; we'd need about 3681 people to donate.
> 
> Assuming we went third-party before Namesys, and that money went from
> a third-party's Paypal account to Namesys, we'd need to charge the
> fees twice... a minimum of $94095.23 USD would be required; requiring
> a minimum of 3764 donators at $25 apiece.

Hmm... noticed a small flaw in the calculations -- the calculations
are based on the "merchant" rate; which require a constant flow of
transactions -- since this is more likely to be a one-time thing, this
would probably be charged at the "standard rate"; at 2.9%.  That means
the third-party would require $95456.79 USD; or 3819 donators at $25
apiece.  Straight to Namesys would require $92688.26 USD; or 3708
donators at $25 apiece.  Geez, Paypal is full of nothing but thieves
and crooks.  *evil glare*

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

Re: reiser4 performance

[Bedros Hanounik]

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

how many people are on reiserfs-list? 

On 8/8/05, michael chang <thenewme91@gmail.com> wrote:
> 
> On 8/8/05, michael chang <thenewme91@gmail.com> wrote:
> > On 8/8/05, David Masover <ninja@slaphack.com> wrote:
> > > PFC wrote:
> > > >>> If only it had a resizer :(
> > > > I would definitely give $25 for the repacker, which is the
> > > > mandatory condition to get the resizer. How many people would give 
> $25
> > > > too ? why not do a little fundraising ?
> > > I would give $25 before it is done, only if it will be F/OSS. I would
> > > give $25 _after_ it's done to get my own personal, proprietary copy.
> 
> > Assuming we went the Paypal route via Fundable.org <http://Fundable.org>and the money went
> > straight to a Namesys Paypal Merchant account; we'd need $ 92024.84
> > USD before the 2.2% and $.30 USD deduction. Assuming that every
> > person donated $25 (which will obviously not be the case; some will
> > donate more; some might less if we have to scrounge around, which we
> > might) ; we'd need about 3681 people to donate.
> >
> > Assuming we went third-party before Namesys, and that money went from
> > a third-party's Paypal account to Namesys, we'd need to charge the
> > fees twice... a minimum of $94095.23 USD would be required; requiring
> > a minimum of 3764 donators at $25 apiece.
> 
> Hmm... noticed a small flaw in the calculations -- the calculations
> are based on the "merchant" rate; which require a constant flow of
> transactions -- since this is more likely to be a one-time thing, this
> would probably be charged at the "standard rate"; at 2.9%. That means
> the third-party would require $95456.79 USD; or 3819 donators at $25
> apiece. Straight to Namesys would require $92688.26 USD; or 3708
> donators at $25 apiece. Geez, Paypal is full of nothing but thieves
> and crooks. *evil glare*
> 
> --
> ~Mike
> - Just my two cents
> - No man is an island, and no man is unable.
>

[-- Attachment #2: Type: text/html, Size: 2587 bytes --]

Re: reiser4 performance

[michael chang]

On 8/8/05, Bedros Hanounik <2bedros@gmail.com> wrote:
> On 8/8/05, michael chang <thenewme91@gmail.com> wrote:
> > On 8/8/05, michael chang <thenewme91@gmail.com> wrote:
> > > On 8/8/05, David Masover <ninja@slaphack.com> wrote:
> > > > PFC wrote: 
> > > > >>> If only it had a resizer :(
> > > > >     I would definitely give $25 for the repacker, which is the
> > > > > mandatory  condition to get the resizer. How many people would give
> $25 
> > > > > too ? why not  do a little fundraising ?
> > > > I would give $25 before it is done, only if it will be F/OSS.  I would
> > > > give $25 _after_ it's done to get my own personal, proprietary copy. 
> > 
> > > Assuming we went the Paypal route via Fundable.org and the money went
> > > straight to a Namesys Paypal Merchant account; we'd need $ 92024.84
> > > USD before the 2.2% and $.30 USD deduction.  Assuming that every 
> > > person donated $25 (which will obviously not be the case; some will
> > > donate more; some might less if we have to scrounge around, which we
> > > might) ; we'd need about 3681 people to donate.
> > >
> > > Assuming we went third-party before Namesys, and that money went from
> > > a third-party's Paypal account to Namesys, we'd need to charge the
> > > fees twice... a minimum of $94095.23 USD would be required; requiring 
> > > a minimum of 3764 donators at $25 apiece.
> > 
> > Hmm... noticed a small flaw in the calculations -- the calculations
> > are based on the "merchant" rate; which require a constant flow of
> > transactions -- since this is more likely to be a one-time thing, this 
> > would probably be charged at the "standard rate"; at 2.9%.  That means
> > the third-party would require $95456.79 USD; or 3819 donators at $25
> > apiece.  Straight to Namesys would require $92688.26 USD; or 3708 
> > donators at $25 apiece.  Geez, Paypal is full of nothing but thieves
> > and crooks.  *evil glare*

> how many people are on reiserfs-list? 

Good question.  How many are willing to pay $25 dollars or so?

Don't you hate readjusting numbers?  I believe it's been less than 15
minutes... and I find that Fundable says that Paypal deducts 4% for
transactions over $1000... so assuming that... it's 4%, followed by
2.9% to recieve to a Paypal account, followed by another 2.9% if it
has to be transferred to another Paypal account because the account
setting up wasn't owned by Namesys.  Does anyone know of any
alternatives to Fundable.org (apart from manually watching incoming
payments at the risk that cancellation may cause fees to be charged on
top of returned payments -- *sigh*)?

To get $90 000 USD for Reiser4
===== ===== ===== ===== =====

If Paypal account used on Fundable.org is owned by Namesys:
Required before Fees: $ 96550.25
Donators at $25 ea: 3863 (-- mostly because of that last evil quarter
-- if Hans is willing take about 24-25 cents less, we can get away
with one less donor).

If Paypal account used on Fundable.org is NOT owned by Namesys, so
that fees have to be transferred to Namesys via another Paypal
account:
Required before Fees: $99434.13
Donators at $25 ea: 3978 (That stupid quarter in case 1 is annoying
IMHO; especially if it causes the Fundable to refund everyone money
because we're 24 cents short after everything.  *sigh*)

I don't know how we'd manage to get funds from a Paypal account to
Namesys's WorldPay account though -- we'd need to put it through a
Credit Card or something, it looks like.

Do note that these are all aproximations (albeit I'm trying to be as
accurate as possible, but there is only so much you can go; like how
4% is calculated and then trimmed).

You also have to wonder, if we use Fundable.org; are we going to set
the timeframe to 2, 4, or 6 weeks -- or are we going to contact
Fundable and ask them to set the timeframe longer (e.g. 8 weeks). 
Though we also have to remember whether or not an extended fundraising
campaign will end up so that we're fundraising beyond when the resizer
would be available anyways (unlikely, unless we end up setting a
timeframe months or years in the future).

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

Re: reiser4 performance

[Ingo Bormuth]

On 2005-08-08 16:58, michael chang wrote:
> To get $90 000 USD for Reiser4
> ===== ===== ===== ===== =====
> 
> If Paypal account used on Fundable.org is owned by Namesys:
> Required before Fees: $ 96550.25
> Donators at $25 ea: 3863 (-- mostly because of that last evil quarter
> [...] 
> You also have to wonder, if we use Fundable.org; are we going to set
> the timeframe to 2, 4, or 6 weeks -- or are we going to contact
> Fundable and ask them to set the timeframe longer (e.g. 8 weeks). 
> Though we also have to remember whether or not an extended fundraising
> campaign will end up so that we're fundraising beyond when the resizer
> would be available anyways (unlikely, unless we end up setting a
> timeframe months or years in the future).
> 

Think about the historic firefox-NYT-add-fund. 
They made it up to about 100,000$ in some weeks.

BUT remeber:

- there is excelent public relations and marketing done at mozilla.org 
  and spreadfirefox.org.

- the web browser is the most often used piece of software, end users 
  of all kinds an operation systems use AND ARE AWARE OF using it. 
  Reiser4 on the other hand is a Linux only thing and filesystems 
  in general are transparent to most users.

- I'm sure the firefox campaign did benefit from both the browser war 
  as well the Windows vs Linux war in large parts.

- I would NOT expect such an event to be repeated easily.

Nevertheless, it could be worth trying but by no means 
in a halfhearted way.


-- 
   +--------------------------------------------------------+
   | Ingo Bormuth,  voicebox & telefax: +49-12125-10226517  |
   | GnuPG key 86326EC9 at http://ibormuth.efil.de/contact  |
   +--------------------------------------------------------+

Re: reiser4 performance

[David Masover]

Raymond A. Meijer wrote:
> On Monday 8 August 2005 13:32, Hemiplegic Menehune wrote:
> 
> 
>>Its already as stable as any other fs on my systems and recovers
>>better than most when my battery runs out. Any idea when it will make
>>it into the stable 2.6 kernel?
> 
> 
> If only it had a resizer :(

Resizer isn't such a big deal.  I can usually find enough backup for 
enough of what I want, and I usually get sizes right the first time.

What I want is the repacker, beacuse performance does steadily degrade 
on my Reiser4 systems, eventually getting worse than Reiser3, but not 
worse than VFAT -- probably because my old FAT partitions are on old, 
virus-ridden systems.

I will stick with Reiser4 for now, and hope the repacker comes soon.  I 
don't resize that often, but I'd like to repack every couple weeks or 
so, and it's not worth it to find that much backup (DVDs) that often.

Re: reiser4 performance

[Hans Reiser]

David Masover wrote:

> Raymond A. Meijer wrote:
>
>> On Monday 8 August 2005 13:32, Hemiplegic Menehune wrote:
>>
>>
>>> Its already as stable as any other fs on my systems and recovers
>>> better than most when my battery runs out. Any idea when it will make
>>> it into the stable 2.6 kernel?
>>
>>
>>
>> If only it had a resizer :(
>
>
> Resizer isn't such a big deal.  I can usually find enough backup for
> enough of what I want, and I usually get sizes right the first time.
>
> What I want is the repacker, beacuse performance does steadily degrade
> on my Reiser4 systems, eventually getting worse than Reiser3, 

I am skeptical that it gets worse than V3, unless it is because we
haven't put in all the bitmap optimizations we did for V3.  I wish I
knew how to measure it.....

> but not worse than VFAT -- probably because my old FAT partitions are
> on old, virus-ridden systems.
>
> I will stick with Reiser4 for now, and hope the repacker comes soon. 
> I don't resize that often, but I'd like to repack every couple weeks
> or so, and it's not worth it to find that much backup (DVDs) that often.
>
>
>

Re: reiser4 performance

[David Masover]

Hans Reiser wrote:
> David Masover wrote:
> 
> 
>>Raymond A. Meijer wrote:
>>
>>
>>>On Monday 8 August 2005 13:32, Hemiplegic Menehune wrote:
>>>
>>>
>>>
>>>>Its already as stable as any other fs on my systems and recovers
>>>>better than most when my battery runs out. Any idea when it will make
>>>>it into the stable 2.6 kernel?
>>>
>>>
>>>
>>>If only it had a resizer :(
>>
>>
>>Resizer isn't such a big deal.  I can usually find enough backup for
>>enough of what I want, and I usually get sizes right the first time.
>>
>>What I want is the repacker, beacuse performance does steadily degrade
>>on my Reiser4 systems, eventually getting worse than Reiser3, 
> 
> 
> I am skeptical that it gets worse than V3, unless it is because we
> haven't put in all the bitmap optimizations we did for V3.  I wish I
> knew how to measure it.....

Me too.  It's fairly subjective on my part, so maybe not.  After all, 
I've gone from lots-of-tiny-partitions to one-huge-root-partition at the 
same time as I switched from v3 to v4, and I know that most of this is 
probably /usr/portage.  With a repacker, Reiser4 would be the best FS 
for /usr/portage -- it's over a hundred thousand shell scripts and text 
files which get updated usually once a day or once a week with rsync -- 
but without a repacker, it's best kept on a separate partition.

Re: reiser4 performance

[michael chang]

On 8/8/05, David Masover <ninja@slaphack.com> wrote:
> Hans Reiser wrote:
> > David Masover wrote:
> >>Raymond A. Meijer wrote:
> >>>On Monday 8 August 2005 13:32, Hemiplegic Menehune wrote:
> >>>>Its already as stable as any other fs on my systems and recovers
> >>>>better than most when my battery runs out. Any idea when it will make
> >>>>it into the stable 2.6 kernel?
> >>>If only it had a resizer :(
> >>Resizer isn't such a big deal.  I can usually find enough backup for
> >>enough of what I want, and I usually get sizes right the first time.

I want a resizer (or at least a converter so I can convert to
ResierFS, resize, and reconvert back) because I have a dual-boot WinXP
and Linux/ReiserFS 3.6 system, which I really want to convert to
Reiser4.  I don't mind putting XP on a FAT partition so I can squeeze
it as much as necessary, but only if I can resize my Resier4 partition
as necessary (I don't mind putting at the top of my HD though, atm...)

> >>What I want is the repacker, beacuse performance does steadily degrade
> >>on my Reiser4 systems, eventually getting worse than Reiser3,
> > I am skeptical that it gets worse than V3, unless it is because we
> > haven't put in all the bitmap optimizations we did for V3.  I wish I
> > knew how to measure it.....
> 
> Me too.  It's fairly subjective on my part, so maybe not.  After all,

Is there a way to count the number of jumps in a file, and the
distance of those jumps when reading a file?  Could the sum or product
of these be some sort of measure of performance (provided that putting
part of a file at the beginning and another part at the end of a disk
don't actually improve performance in some twisted way due to using
different heads simultaneously or something)?

> I've gone from lots-of-tiny-partitions to one-huge-root-partition at the
> same time as I switched from v3 to v4, and I know that most of this is
> probably /usr/portage.  With a repacker, Reiser4 would be the best FS
> for /usr/portage -- it's over a hundred thousand shell scripts and text

It'd be the best FS for just about anyone who likes to tinker, or
anyone with a mid-range system that has a really slow, slow hard
drive.  My newest hard drive also happens to be my slowest... *sigh*

> but without a repacker, it's best kept on a separate partition.

So are many things, it seems.  Sadly.

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

Re: reiser4 performance

[David Masover]

michael chang wrote:
> On 8/8/05, David Masover <ninja@slaphack.com> wrote:
> 
>>Hans Reiser wrote:
>>
>>>David Masover wrote:
>>>
>>>>Raymond A. Meijer wrote:
>>>>
>>>>>On Monday 8 August 2005 13:32, Hemiplegic Menehune wrote:
>>>>>
>>>>>>Its already as stable as any other fs on my systems and recovers
>>>>>>better than most when my battery runs out. Any idea when it will make
>>>>>>it into the stable 2.6 kernel?
>>>>>
>>>>>If only it had a resizer :(
>>>>
>>>>Resizer isn't such a big deal.  I can usually find enough backup for
>>>>enough of what I want, and I usually get sizes right the first time.
> 
> 
> I want a resizer (or at least a converter so I can convert to
> ResierFS, resize, and reconvert back) because I have a dual-boot WinXP
> and Linux/ReiserFS 3.6 system, which I really want to convert to
> Reiser4.

That's about my situation.

> I don't mind putting XP on a FAT partition so I can squeeze

Dear God, no!  Learn to use ntfsresize.  It doesn't even require that 
you defragment first -- it will defragment an NTFS partition in order to 
shrink it, then set a flag that tells Windows to run its equivalent of 
fsck on the next boot.

The only reason for using VFAT would be if you have a lot of large files 
shared between Windows/Linux -- Captive is slow.  But I'd rather have a 
fast Windows and a slow (mostly unused) Captive any day.

> it as much as necessary, but only if I can resize my Resier4 partition
> as necessary (I don't mind putting at the top of my HD though, atm...)

I eventually figured out how to resize stuff properly.  But, what I'd 
like to be able to do is grow any partition both ways.  I don't care so 
much about ntfsresize, since I keep my Windows partition near the front 
of the disk (to boost the speed of Windows -- for Linux, I have Reiser), 
but I'd like to be able to move the beginning of the FS -- either 
backwards, to grab unused Windows space, or forwards, to give space back 
to Windows.

But, without that, there's always LVM.  It will fragment your partition, 
at a level below the FS, but it will let you grow and shrink stuff any 
way you like, including onto new devices.  But I don't do that, because 
I doubt I'm wrong about how much each will grow, and I like performance 
and software RAID, neither of which is easy with LVM.

And, of course, there's a ludicrously long and dangerous route -- create 
two dm_linear devices that overlap, dd from one to the other to move an 
FS backwards, then grow it once it's on the second device.  If only the 
Device-Mapper modules were documented!

>>>>What I want is the repacker, beacuse performance does steadily degrade
>>>>on my Reiser4 systems, eventually getting worse than Reiser3,
>>>
>>>I am skeptical that it gets worse than V3, unless it is because we
>>>haven't put in all the bitmap optimizations we did for V3.  I wish I
>>>knew how to measure it.....
>>
>>Me too.  It's fairly subjective on my part, so maybe not.  After all,
> 
> 
> Is there a way to count the number of jumps in a file, and the
> distance of those jumps when reading a file?  Could the sum or product
> of these be some sort of measure of performance (provided that putting
> part of a file at the beginning and another part at the end of a disk
> don't actually improve performance in some twisted way due to using
> different heads simultaneously or something)?

Yeah, that'd be a bit unreliable.  Even on desktop machines, we're 
getting something called NCQ, meaning the really severely fragmented 
files won't be quite as slow as you'd predict.  Also, aside from the 
different heads, there's a striped RAID -- also within reach of a 
desktop power user like myself.

Re: reiser4 performance

[michael chang]

On 8/8/05, David Masover <ninja@slaphack.com> wrote:
> michael chang wrote:
> > On 8/8/05, David Masover <ninja@slaphack.com> wrote:
> >
> >>Hans Reiser wrote:
> >>
> >>>David Masover wrote:
> >>>
> >>>>Raymond A. Meijer wrote:
> >>>>
> >>>>>On Monday 8 August 2005 13:32, Hemiplegic Menehune wrote:
> >>>>>
> >>>>>>Its already as stable as any other fs on my systems and recovers
> >>>>>>better than most when my battery runs out. Any idea when it will make
> >>>>>>it into the stable 2.6 kernel?
> >>>>>
> >>>>>If only it had a resizer :(
> >>>>
> >>>>Resizer isn't such a big deal.  I can usually find enough backup for
> >>>>enough of what I want, and I usually get sizes right the first time.
> >
> >
> > I want a resizer (or at least a converter so I can convert to
> > ResierFS, resize, and reconvert back) because I have a dual-boot WinXP
> > and Linux/ReiserFS 3.6 system, which I really want to convert to
> > Reiser4.
> 
> That's about my situation.
> 
> > I don't mind putting XP on a FAT partition so I can squeeze
> 
> Dear God, no!  Learn to use ntfsresize.  It doesn't even require that
> you defragment first -- it will defragment an NTFS partition in order to
> shrink it, then set a flag that tells Windows to run its equivalent of
> fsck on the next boot.

But the start of a NTFS parition is fixed.  So is that of ResierFS
3.6, in parted.  Besides, when my hard drive is 99% full and all the
files that need to be defragmented are in the MFT area, I really think
FAT is saner.  I had that happen to me before.  Honest.

> The only reason for using VFAT would be if you have a lot of large files
> shared between Windows/Linux -- Captive is slow.  But I'd rather have a
> fast Windows and a slow (mostly unused) Captive any day.

I have yet to get Captive working.  I use a plain Debian install.  I'm
kinda waiting for Ubantu disks in the mail -- I'll experiment with
those later. In the meantime, still running unstable Debian.  *sighs*

> I eventually figured out how to resize stuff properly.  But, what I'd
> like to be able to do is grow any partition both ways.  I don't care so
> much about ntfsresize, since I keep my Windows partition near the front
> of the disk (to boost the speed of Windows -- for Linux, I have Reiser),

Obviously, you and I have different opinions to solve the same
problem.  Since I try and squeeze around 17 GBs or so of stuff on 2
partitions on a 20 GB disk, then I have loads of problems.  At this
rate, I'm going to put /boot on a ext2 partition at the top, then put
in a Reiser4 partition, then my FAT windows partition.

FAT seems to defragment easier than NTFS when full.  Emphasis on the
full bit.  My partitions are always full, never empty.  No time.  Why?
 Because I don't have a CD/DVD burner to offload stuff.  That's why.

> but I'd like to be able to move the beginning of the FS -- either
> backwards, to grab unused Windows space, or forwards, to give space back
> to Windows.

I used to do this.  Then I found that Ext2 and ResierFS's beginnings
won't budge.  So I just tacked my FAT partition at the end.  Who needs
Windows anyways?  At the rate it was going, there wouldn't have been a
performance gain putting it at the beginning.  I spend most of my time
in Linux.

> But, without that, there's always LVM.  It will fragment your partition,
> at a level below the FS, but it will let you grow and shrink stuff any
> way you like, including onto new devices.  But I don't do that, because
> I doubt I'm wrong about how much each will grow, and I like performance
> and software RAID, neither of which is easy with LVM.

But I hate trying to do this while keeping my siblings' files and my
parents' files on the same disk.  And I absolutely HATE software
raid/LVM.  Which is why I don't use it.  Fragmentation is my worse
enemy, and I'd spend two days defragmenting a computer if I need to. 
[I just did, and it's still half fragmented; mostly due to files that
take up about 1/100th of the disk or so.]

> different heads, there's a striped RAID -- also within reach of a
> desktop power user like myself.

Striped RAID only works if you have multiple disks and a decent bus. 
I'm stuck on the lowest-end Dell Dimension 3000, with one of the
slowest hard drives in history.  And I haven't gotten around to
opening the case... yet.

Every consumer has different values, and different approaches.  Some
are still as stubborn as a mule, and you have to accomidate for them,
or lose them.

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

Re: reiser4 performance

[Valdis.Kletnieks]

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

On Tue, 09 Aug 2005 13:52:49 EDT, michael chang said:

> Striped RAID only works if you have multiple disks and a decent bus. 
> I'm stuck on the lowest-end Dell Dimension 3000, with one of the
> slowest hard drives in history.  And I haven't gotten around to
> opening the case... yet.

Newbie. ;)

IBM 2314 disk drive for the S/360, late 60s. 10 14" platters, 3600RPM, 29M of
storage capacity, 650Kbytes/second transfer rate.  And that was a fast
mainframe drive for its day.

Now what was this about slow tiny drives? ;)

And if you think a seek hurts latency on modern disk drives, you should have
seen what an end-to-end seek did on a filesystem on a DECTape (yes, the tape
had addressable blocks, you could (and many people did) put a filesystem on it).

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

Re: reiser4 performance

[David Masover]

michael chang wrote:
> On 8/8/05, David Masover <ninja@slaphack.com> wrote:
> 
>>michael chang wrote:
>>
>>>On 8/8/05, David Masover <ninja@slaphack.com> wrote:
>>>
>>>
>>>>Hans Reiser wrote:
>>>>
>>>>
>>>>>David Masover wrote:
>>>>>
>>>>>
>>>>>>Raymond A. Meijer wrote:
>>>>>>
>>>>>>
>>>>>>>On Monday 8 August 2005 13:32, Hemiplegic Menehune wrote:
>>>>>>>
>>>>>>>
>>>>>>>>Its already as stable as any other fs on my systems and recovers
>>>>>>>>better than most when my battery runs out. Any idea when it will make
>>>>>>>>it into the stable 2.6 kernel?
>>>>>>>
>>>>>>>If only it had a resizer :(
>>>>>>
>>>>>>Resizer isn't such a big deal.  I can usually find enough backup for
>>>>>>enough of what I want, and I usually get sizes right the first time.
>>>
>>>
>>>I want a resizer (or at least a converter so I can convert to
>>>ResierFS, resize, and reconvert back) because I have a dual-boot WinXP
>>>and Linux/ReiserFS 3.6 system, which I really want to convert to
>>>Reiser4.
>>
>>That's about my situation.
>>
>>
>>>I don't mind putting XP on a FAT partition so I can squeeze
>>
>>Dear God, no!  Learn to use ntfsresize.  It doesn't even require that
>>you defragment first -- it will defragment an NTFS partition in order to
>>shrink it, then set a flag that tells Windows to run its equivalent of
>>fsck on the next boot.
> 
> 
> But the start of a NTFS parition is fixed.  So is that of ResierFS
> 3.6, in parted.  Besides, when my hard drive is 99% full and all the
> files that need to be defragmented are in the MFT area, I really think
> FAT is saner.  I had that happen to me before.  Honest.

Wait, are you saying the start of a FAT partition will move?

>>I eventually figured out how to resize stuff properly.  But, what I'd
>>like to be able to do is grow any partition both ways.  I don't care so
>>much about ntfsresize, since I keep my Windows partition near the front
>>of the disk (to boost the speed of Windows -- for Linux, I have Reiser),
> 
> 
> Obviously, you and I have different opinions to solve the same
> problem.  Since I try and squeeze around 17 GBs or so of stuff on 2
> partitions on a 20 GB disk, then I have loads of problems.  At this
> rate, I'm going to put /boot on a ext2 partition at the top, then put
> in a Reiser4 partition, then my FAT windows partition.
> 
> FAT seems to defragment easier than NTFS when full.  Emphasis on the
> full bit.  My partitions are always full, never empty.  No time.  Why?
>  Because I don't have a CD/DVD burner to offload stuff.  That's why.

It's probably not polite to say this, but CD/DVD burners are quite cheap 
these days, as is storage in general.  For something like $120 each, I 
got a pair of 250 gig hard drives.  DVD burners are more like $50, plus 
$20 gets you 100 blank write-once single-layer DVDs.

And you do know about the 75% rule, right?

>>but I'd like to be able to move the beginning of the FS -- either
>>backwards, to grab unused Windows space, or forwards, to give space back
>>to Windows.
> 
> 
> I used to do this.  Then I found that Ext2 and ResierFS's beginnings
> won't budge.  So I just tacked my FAT partition at the end.  Who needs
> Windows anyways?  At the rate it was going, there wouldn't have been a
> performance gain putting it at the beginning.  I spend most of my time
> in Linux.

This also makes me think you're saying FAT resizes both ways...

>>different heads, there's a striped RAID -- also within reach of a
>>desktop power user like myself.
> 
> 
> Striped RAID only works if you have multiple disks and a decent bus. 
> I'm stuck on the lowest-end Dell Dimension 3000, with one of the
> slowest hard drives in history.  And I haven't gotten around to
> opening the case... yet.
> 
> Every consumer has different values, and different approaches.  Some
> are still as stubborn as a mule, and you have to accomidate for them,
> or lose them.

I don't work here, but believe me, they are trying.  It seems they are 
still trying to get in the mainstream kernel, which means dealing with 
lots of stubborn people...

Re: reiser4 performance

[Hans Reiser]

David Masover wrote:

>>
>>
>> I am skeptical that it gets worse than V3, unless it is because we
>> haven't put in all the bitmap optimizations we did for V3.  I wish I
>> knew how to measure it.....
>
>
> Me too.  It's fairly subjective on my part, so maybe not.  After all,
> I've gone from lots-of-tiny-partitions to one-huge-root-partition at
> the same time as I switched from v3 to v4, and I know that most of
> this is probably /usr/portage.  With a repacker, Reiser4 would be the
> best FS for /usr/portage -- it's over a hundred thousand shell scripts
> and text files which get updated usually once a day or once a week
> with rsync -- but without a repacker, it's best kept on a separate
> partition.
>
>
>
Yes, that usage pattern likely needs a repacker.

Re: reiser4 performance

[Hans Reiser]

Hemiplegic Menehune wrote:

>Hi,
>
>I just wanted to say thank you for putting together reiser4 :)
>
>I just upgraded to the latest -mm kernel on my box and my jaw is on the 
>floor looking at the performance of reiser4. I have previously played around 
>with it on a few occasions, but I never had the chance to test it with my 
>software before - it is literally 3 times as fast as reiserfs3 (which itself 
>is twice as fast as ext3) - how did you guys do it? :)
>
>The only thing reiser4 runs slower than ext3 is postgresql!
>
>Its already as stable as any other fs on my systems and recovers better than 
>most when my battery runs out. Any idea when it will make it into the stable 
>2.6 kernel?
>
>- HM
>
>
>
>
>
>  
>
Please post to lkml with this. ;-)

We hope soon.

Re: reiser4 performance

[Hans Reiser]

I should add that fsync performance has not been worked on yet, which is
surely why postgres performance is poor.

Hans

Hemiplegic Menehune wrote:

>Hi,
>
>I just wanted to say thank you for putting together reiser4 :)
>
>I just upgraded to the latest -mm kernel on my box and my jaw is on the 
>floor looking at the performance of reiser4. I have previously played around 
>with it on a few occasions, but I never had the chance to test it with my 
>software before - it is literally 3 times as fast as reiserfs3 (which itself 
>is twice as fast as ext3) - how did you guys do it? :)
>
>The only thing reiser4 runs slower than ext3 is postgresql!
>
>Its already as stable as any other fs on my systems and recovers better than 
>most when my battery runs out. Any idea when it will make it into the stable 
>2.6 kernel?
>
>- HM
>
>
>
>
>
>  
>

Re: reiser4 performance

[Gregory Maxwell]

On 8/8/05, Hans Reiser <reiser@namesys.com> wrote:
> I should add that fsync performance has not been worked on yet, which is
> surely why postgres performance is poor.

Hans, I'm on the postgresql hackers list (although I don't really have
a voice there, so I can't really speak much for reiser4 there)..

One of the 'interesting' issues they face is that that postgresql
database works with 8K pages.  From a performance and reliability
perspective they would benefit impressively from a file system (and
VFS) which could atomically update their 8k pages. Without such a
feature their performance is slaughtered when operating in a mode that
provides the highest reliability, and their reliability is slaughtered
when operating in the highest performance configuration.

I'm sure the PostgreSQL folks would be here themselves asking for help
with this issue... if they weren't so oriented around FreeBSD. :)

If ever you are looking for a killer app for Reiser4 that people who
don't care about the visionary stuff will care about: you couldn't
find one better than postgresql. If you could get postgresql working
as reliably as a double logged full fsync configuration but performing
as fast as a configuration with async writes.... you'd have a lot more
supporters.

Re: reiser4 performance

[Hans Reiser]

Gregory Maxwell wrote:

>On 8/8/05, Hans Reiser <reiser@namesys.com> wrote:
>  
>
>>I should add that fsync performance has not been worked on yet, which is
>>surely why postgres performance is poor.
>>    
>>
>
>Hans, I'm on the postgresql hackers list (although I don't really have
>a voice there, so I can't really speak much for reiser4 there)..
>
>One of the 'interesting' issues they face is that that postgresql
>database works with 8K pages.  From a performance and reliability
>perspective they would benefit impressively from a file system (and
>VFS) which could atomically update their 8k pages. Without such a
>feature their performance is slaughtered when operating in a mode that
>provides the highest reliability, and their reliability is slaughtered
>when operating in the highest performance configuration.
>
>I'm sure the PostgreSQL folks would be here themselves asking for help
>with this issue... if they weren't so oriented around FreeBSD. :)
>
>If ever you are looking for a killer app for Reiser4 that people who
>don't care about the visionary stuff will care about: you couldn't
>find one better than postgresql. If you could get postgresql working
>as reliably as a double logged full fsync configuration but performing
>as fast as a configuration with async writes.... you'd have a lot more
>supporters.
>
>
>  
>
Well I would be very happy to do that.  In fact, if they use 8k writes,
we already do that.  If they need to use mmap while being atomic, well,
that is more complex, and if someone sponsors it we will do it.  Right
now we don't have much resources to spare as we complete the work needed
to go into the kernel.

Thanks for a very interesting remark....

Hans

Re: reiser4 performance

[David Masover]

Gregory Maxwell wrote:
> On 8/8/05, Hans Reiser <reiser@namesys.com> wrote:

> If ever you are looking for a killer app for Reiser4 that people who
> don't care about the visionary stuff will care about:

Define "visionary"?

I can name a few things that work best in Reiser4, and very well in v3, 
simply because of efficient storage of small files and lazy allocation:

webserver -- lots of small files, very few large ones, mostly reads
mailserver -- especially IMAP+maildir, lots of small files, read/write
and so on...

Gentoo box:
	/usr/portage is over a hundred thousand very small files, updated via 
rsync.  Since they are updated all at once, you get a boost out of lazy 
allocation -- you only touch the disks for reads while you're talking to 
the server, because most of the writes probably won't hit the disk for 
awhile.
	/var/tmp/portage is what Portage uses for compilation.  A source 
tarball (usually a tarball, can be anything) is unpacked from 
/usr/portage/distfiles into /var/tmp/portage/<package>/build.  It's 
compiled, then installed into /var/tmp/portage/<package>/install, then 
Portage manually merges the /install directory with the main filesystem, 
in one operation -- presumably so that it could become atomic someday. 
After the merge, /var/tmp/portage is cleaned for the next package.
	With enough RAM, most of the contents (source code and object files) 
from /var/tmp/portage would never touch disk.  This becomes an 
especially huge win if your /var/tmp/portage is a separate partition -- 
instead of writing (unpack tarball), then reading, then writing again 
(for install/merge), you write once.  What was a 5, 6, or 7-step process 
is now a 1-step process.  And, if you don't have enough RAM for this 
RAM-disk-like behavior, it falls back to the old way.

These are all things that Reiser4 already does better than anything 
else.  So now we're going to get Postgres to run faster.  I can't wait 
until we have more people hacking on the plugin interface -- then we'll 
have some *real* killer apps.

Re: reiser4 performance

[Gregory Maxwell]

On 8/8/05, David Masover <ninja@slaphack.com> wrote:
> Gregory Maxwell wrote:
> > On 8/8/05, Hans Reiser <reiser@namesys.com> wrote:
> 
> > If ever you are looking for a killer app for Reiser4 that people who
> > don't care about the visionary stuff will care about:
> 
> Define "visionary"?
> 
> I can name a few things that work best in Reiser4, and very well in v3,
> simply because of efficient storage of small files and lazy allocation:
> 
> webserver -- lots of small files, very few large ones, mostly reads

Given webserver horsepower from the same budget class as the Internet
pipe it is attached to, it is utterly trivial to saturate the pipe
with static content.. even if the files are small, larger than core in
total, and have poor locality.   (and those are very infrequently the
case).

So for most webserver cases, FS speed doesn't matter. For the few
cases where it does, locality is usually fairly good... so who cares
if the new FS is 2x faster, when it is still 200x slower than ram. Add
ram.

> mailserver -- especially IMAP+maildir, lots of small files, read/write
> and so on...

An interesting application space, no doubt. Although you can cure a
lot of sins tossing solid state disk at it. :) (or just battery backed
cache on a hardware raid controller).

> Gentoo box:
>         /usr/portage is over a hundred thousand very small files, updated via
> rsync.  Since they are updated all at once, you get a boost out of lazy
[snip]

Rsync algo or the network is going to be your bottleneck there, for
the sync... Are you really getting disk bound for compile? if so
increase your -j N.


> These are all things that Reiser4 already does better than anything
> else.  So now we're going to get Postgres to run faster.  I can't wait
> until we have more people hacking on the plugin interface -- then we'll
> have some *real* killer apps.

I agree. Still it would be nice to have some really good bread and
butter improvements.. and a sufficient level of 'transaction' support
exposed to PostgreSQL could result in a huge performance improvement
while improving reliability. "Your database is more reliable on
reiser4" would be a compelling argument... even to those not convinced
by plugins and small files.

Re: reiser4 performance

[David Masover]

Gregory Maxwell wrote:
> On 8/8/05, David Masover <ninja@slaphack.com> wrote:
> 
>>Gregory Maxwell wrote:
>>
>>>On 8/8/05, Hans Reiser <reiser@namesys.com> wrote:
>>
>>>If ever you are looking for a killer app for Reiser4 that people who
>>>don't care about the visionary stuff will care about:
>>
>>Define "visionary"?
>>
>>I can name a few things that work best in Reiser4, and very well in v3,
>>simply because of efficient storage of small files and lazy allocation:
>>
[...]
>>mailserver -- especially IMAP+maildir, lots of small files, read/write
>>and so on...
> 
> 
> An interesting application space, no doubt. Although you can cure a
> lot of sins tossing solid state disk at it. :) (or just battery backed
> cache on a hardware raid controller).

Ok, we were talking about budget class before, and now we're talking 
about solid state disks?  Some people run much smaller IMAP servers, 
where it actually matters if an FS is twice as fast.  Especially for 
full-text searches on a server that doesn't do indexing -- and none of 
the existing ones do real-time indexing.

>>Gentoo box:
>>        /usr/portage is over a hundred thousand very small files, updated via
>>rsync.  Since they are updated all at once, you get a boost out of lazy
> 
> [snip]
> 
> Rsync algo or the network is going to be your bottleneck there, for
> the sync...

Want to bet?  Try it.  I can say with a reasonable amount of certainty 
that it's my FS/disk that's the bottleneck with my local rsync server -- 
the server is heavily disk-bound --  and even with my older boxes if I 
have them syncing directly to the Internet.

> Are you really getting disk bound for compile? if so
> increase your -j N.

Not all Gentoo packages need much of a compile.  Some need none at all.

For example:  Netcat is a single binary, and I believe it's even a 
single GCC command.  Most of Portage's helper scripts are Bash or 
Python, and while Python compiles a little, the "compile" stage for Bash 
is a nullop.

Besides, the parts of this that don't relate directly to compiling still 
apply -- that is, the unpack/install/merge -- even for something that 
compiles.

>>These are all things that Reiser4 already does better than anything
>>else.  So now we're going to get Postgres to run faster.  I can't wait
>>until we have more people hacking on the plugin interface -- then we'll
>>have some *real* killer apps.
> 
> 
> I agree. Still it would be nice to have some really good bread and
> butter improvements.. and a sufficient level of 'transaction' support
> exposed to PostgreSQL could result in a huge performance improvement
> while improving reliability. "Your database is more reliable on
> reiser4" would be a compelling argument... even to those not convinced
> by plugins and small files.

Absolutely.  I'm not knocking your idea, just wanted to clarify that 
"Reiser4 would be great if..." is getting old.  It is great, and it's 
getting even better pretty fast.

And, by the way, if the transaction interface gets done, it's not just 
databases that will benefit, but also small files.  After all, what kind 
of transactions are used for your OpenOffice document?  Or your source 
code -- should that really be the job of a text editor?  For someone 
making their living as a writer or a programmer, that's much more 
important than some inane database that keeps their icons looking 
pretty, or a SQL behemoth that'll never be on their machine.

Re: reiser4 performance

[Gregory Maxwell]

On 8/8/05, David Masover <ninja@slaphack.com> wrote:
> "Reiser4 would be great if..." is getting old.  It is great, and it's
> getting even better pretty fast.
> 
> And, by the way, if the transaction interface gets done, it's not just
> databases that will benefit, but also small files.  After all, what kind
> of transactions are used for your OpenOffice document?  
...

Well there doesn't actually need to be a transaction interface for
postgresql's needs.. it just needs a fairly limited set of assurances
from the VFS/FS that ... aren't usually provided. Beyond that, it
already handles its own transactions.  It looks like from Hans' reply
the reiser4 already provides everything needed.. which I had
suspected.

Re: reiser4 performance

[Hans Reiser]

Gregory Maxwell wrote:

>On 8/8/05, David Masover <ninja@slaphack.com> wrote:
>  
>
>>"Reiser4 would be great if..." is getting old.  It is great, and it's
>>getting even better pretty fast.
>>
>>And, by the way, if the transaction interface gets done, it's not just
>>databases that will benefit, but also small files.  After all, what kind
>>of transactions are used for your OpenOffice document?  
>>    
>>
>...
>
>Well there doesn't actually need to be a transaction interface for
>postgresql's needs.. it just needs a fairly limited set of assurances
>from the VFS/FS that ... aren't usually provided. Beyond that, it
>already handles its own transactions.  It looks like from Hans' reply
>the reiser4 already provides everything needed.. which I had
>suspected.
>
>
>  
>
Well, but then you have to tell postgres that it can assume these things
about reiser4.....

Re: reiser4 performance

[PFC]

> Well, but then you have to tell postgres that it can assume these things
> about reiser4.....

you can already set the sync mode in the config file to a llot of  
different choices, like fdatasync, fsync, O_SYNC, etc, so a reiser4 option  
would be possibel I guess.

Re: reiser4 performance

[Gregory Maxwell]

On 8/11/05, PFC <lists@boutiquenumerique.com> wrote:
> 
> > Well, but then you have to tell postgres that it can assume these things
> > about reiser4.....
> 
> you can already set the sync mode in the config file to a llot of
> different choices, like fdatasync, fsync, O_SYNC, etc, so a reiser4 option
> would be possibel I guess.

Right, and the PostgreSQL team has already shown that they are willing
to create platform specific options.

Could someone familiar with the reiser4 internals provide some
detailed information about what reiser4 currently provides in this
regard?

The specific concerns would be about controlling the ordering and
atomicity of 8k writes and how to tell when they are fixed to the
media.

Re: reiser4 performance

[Gregory Maxwell]

On 8/8/05, David Masover <ninja@slaphack.com> wrote:

> Absolutely.  I'm not knocking your idea, just wanted to clarify that
> "Reiser4 would be great if..." is getting old.  It is great, and it's
> getting even better pretty fast.

(sorry for reply bloat)
I just wanted to point out.. that wasn't my intent. I think the only
'feature' reiser4 needs right now is mainstream inclusion.

My ability to use it is severely hampered only being able to use it on
boxes running test-kernel of the day.. which are laden with other
issues unrelated to reiser4 that I don't have time to deal with.

Re: reiser4 performance

[David Masover]

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

Gregory Maxwell wrote:
> On 8/8/05, David Masover <ninja@slaphack.com> wrote:
[...]
> My ability to use it is severely hampered only being able to use it on
> boxes running test-kernel of the day.. which are laden with other
> issues unrelated to reiser4 that I don't have time to deal with.

How recent a Reiser4 do you need?  There are some patches against the 
vanilla kernel at

http://namesys.com/pub/reiser4-for-2.6/

But those seem out of date and don't work for me.  But, the patches from 
the mm-kernel have been rock-solid for me.  I'm taking the vanilla 
2.6.12.3 kernel and patching it with the Reiser4 patches from 
2.6.12-mm2.  Unpack this:

http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12/2.6.12-mm2/2.6.12-mm2-broken-out.tar.bz2

to /usr/src/ and run this:

#!/bin/sh
# hack to bring mm reiser4 back to vanilla
cd /usr/src/linux
for i in `grep reiser4 ../broken-out/series`; do
	patch -p1 < ../broken-out/$i;
done

I've attached one patch of my own that makes it compile properly -- 
apply after you run the script above.

[-- Attachment #2: reiser4_fix_refrigerator.patch --]
[-- Type: text/plain, Size: 946 bytes --]

diff -Naur linux-2.6.12.2-reiser4/fs/reiser4/entd.c linux-2.6.12.2-reiser4-fix-refrigerator/fs/reiser4/entd.c
--- linux-2.6.12.2-reiser4/fs/reiser4/entd.c	2005-07-04 19:36:42.910932648 +0000
+++ linux-2.6.12.2-reiser4-fix-refrigerator/fs/reiser4/entd.c	2005-07-04 19:39:05.513253800 +0000
@@ -131,7 +131,7 @@
 		int result = 0;
 
 		if (me->flags & PF_FREEZE)
-			refrigerator();
+			refrigerator(PF_FREEZE);
 
 		spin_lock(&ent->guard);
 
diff -Naur linux-2.6.12.2-reiser4/fs/reiser4/ktxnmgrd.c linux-2.6.12.2-reiser4-fix-refrigerator/fs/reiser4/ktxnmgrd.c
--- linux-2.6.12.2-reiser4/fs/reiser4/ktxnmgrd.c	2005-07-04 19:36:42.898934472 +0000
+++ linux-2.6.12.2-reiser4-fix-refrigerator/fs/reiser4/ktxnmgrd.c	2005-07-04 19:39:19.049196024 +0000
@@ -109,7 +109,7 @@
 		/* software suspend support. */
 		if (me->flags & PF_FREEZE) {
 			spin_unlock(&ctx->guard);
-			refrigerator();
+			refrigerator(PF_FREEZE);
 			spin_lock(&ctx->guard);
 		}
 

Re: reiser4 performance

[Pat Double]

Forgive me for moving to private, but I've posted this on the list before 
without comment.

The 2.6.12.x patches and 2.6.12.x applied from -mm have incorrect behavior 
when modifying the root directory. If you add or remove files in the root, 
the filesystem check fails. You can try this on a ram disk or loop file 
system. I'd be interested to see if you'd try it and let me know if you get a 
failed filesystem check. I am able to repair without data loss.

On Tuesday 09 August 2005 08:34 pm, David Masover wrote:
> Gregory Maxwell wrote:
> > On 8/8/05, David Masover <ninja@slaphack.com> wrote:
>
> [...]
>
> > My ability to use it is severely hampered only being able to use it on
> > boxes running test-kernel of the day.. which are laden with other
> > issues unrelated to reiser4 that I don't have time to deal with.
>
> How recent a Reiser4 do you need?  There are some patches against the
> vanilla kernel at
>
> http://namesys.com/pub/reiser4-for-2.6/
>
> But those seem out of date and don't work for me.  But, the patches from
> the mm-kernel have been rock-solid for me.  I'm taking the vanilla
> 2.6.12.3 kernel and patching it with the Reiser4 patches from
> 2.6.12-mm2.  Unpack this:
>
> http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12/2.6.12-mm
>2/2.6.12-mm2-broken-out.tar.bz2
>
> to /usr/src/ and run this:
>
> #!/bin/sh
> # hack to bring mm reiser4 back to vanilla
> cd /usr/src/linux
> for i in `grep reiser4 ../broken-out/series`; do
> 	patch -p1 < ../broken-out/$i;
> done
>
> I've attached one patch of my own that makes it compile properly --
> apply after you run the script above.

-- 
Pat Double, pat@patdouble.com
"In the beginning God created the heaven and the earth."

Re: reiser4 performance

[David Masover]

Pat Double wrote:
> Forgive me for moving to private, but I've posted this on the list before 
> without comment.

Make it public again if you like.

> The 2.6.12.x patches and 2.6.12.x applied from -mm have incorrect behavior 
> when modifying the root directory. If you add or remove files in the root, 
> the filesystem check fails. You can try this on a ram disk or loop file 
> system. I'd be interested to see if you'd try it and let me know if you get a 
> failed filesystem check. I am able to repair without data loss.

I'll have to try it sometime, but not now.  Does this happen on that -mm 
kernel if you apply *all* the patches, not just reiser4-specific? 
(Doing this would eliminate the need for my patch, obviously.)

Incidentally, if you've been watching the list, I recently recovered 
some ungodly amount of data that I'd effectively "rm -rf"ed.  The kernel 
used both to create that catastrophy and to recover from it was a 
2.6.12.2 kernel, patched just as I described, using fsck.reiser4 1.0.4.

> On Tuesday 09 August 2005 08:34 pm, David Masover wrote:
> 
>>Gregory Maxwell wrote:
>>
>>>On 8/8/05, David Masover <ninja@slaphack.com> wrote:
>>
>>[...]
>>
>>
>>>My ability to use it is severely hampered only being able to use it on
>>>boxes running test-kernel of the day.. which are laden with other
>>>issues unrelated to reiser4 that I don't have time to deal with.
>>
>>How recent a Reiser4 do you need?  There are some patches against the
>>vanilla kernel at
>>
>>http://namesys.com/pub/reiser4-for-2.6/
>>
>>But those seem out of date and don't work for me.  But, the patches from
>>the mm-kernel have been rock-solid for me.  I'm taking the vanilla
>>2.6.12.3 kernel and patching it with the Reiser4 patches from
>>2.6.12-mm2.  Unpack this:
>>
>>http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12/2.6.12-mm
>>2/2.6.12-mm2-broken-out.tar.bz2
>>
>>to /usr/src/ and run this:
>>
>>#!/bin/sh
>># hack to bring mm reiser4 back to vanilla
>>cd /usr/src/linux
>>for i in `grep reiser4 ../broken-out/series`; do
>>	patch -p1 < ../broken-out/$i;
>>done
>>
>>I've attached one patch of my own that makes it compile properly --
>>apply after you run the script above.
> 
> 

Re: reiser4 performance

[Pat Double]

Actually I did make it public, hit the wrong command on my mail client ;)

I did not try the -mm kernel (latest patches is for -mm5 IIRC), I use software 
suspend 2 and it does not apply to the 2.6.12.x-mm series. Except for this 
problem reiser4 has worked great for me. Since I use a single partition and 
'/' does not get modified much I copied all my data over, rebuilt the 
filesystem, and then started using it. I have not discovered any problems, 
and the filesystem is quite fast.

On Tuesday 09 August 2005 09:11 pm, David Masover wrote:
> Pat Double wrote:
> > Forgive me for moving to private, but I've posted this on the list before
> > without comment.
>
> Make it public again if you like.
>
> > The 2.6.12.x patches and 2.6.12.x applied from -mm have incorrect
> > behavior when modifying the root directory. If you add or remove files in
> > the root, the filesystem check fails. You can try this on a ram disk or
> > loop file system. I'd be interested to see if you'd try it and let me
> > know if you get a failed filesystem check. I am able to repair without
> > data loss.
>
> I'll have to try it sometime, but not now.  Does this happen on that -mm
> kernel if you apply *all* the patches, not just reiser4-specific?
> (Doing this would eliminate the need for my patch, obviously.)
>
> Incidentally, if you've been watching the list, I recently recovered
> some ungodly amount of data that I'd effectively "rm -rf"ed.  The kernel
> used both to create that catastrophy and to recover from it was a
> 2.6.12.2 kernel, patched just as I described, using fsck.reiser4 1.0.4.
>
> > On Tuesday 09 August 2005 08:34 pm, David Masover wrote:
> >>Gregory Maxwell wrote:
> >>>On 8/8/05, David Masover <ninja@slaphack.com> wrote:
> >>
> >>[...]
> >>
> >>>My ability to use it is severely hampered only being able to use it on
> >>>boxes running test-kernel of the day.. which are laden with other
> >>>issues unrelated to reiser4 that I don't have time to deal with.
> >>
> >>How recent a Reiser4 do you need?  There are some patches against the
> >>vanilla kernel at
> >>
> >>http://namesys.com/pub/reiser4-for-2.6/
> >>
> >>But those seem out of date and don't work for me.  But, the patches from
> >>the mm-kernel have been rock-solid for me.  I'm taking the vanilla
> >>2.6.12.3 kernel and patching it with the Reiser4 patches from
> >>2.6.12-mm2.  Unpack this:
> >>
> >>http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12/2.6.12-
> >>mm 2/2.6.12-mm2-broken-out.tar.bz2
> >>
> >>to /usr/src/ and run this:
> >>
> >>#!/bin/sh
> >># hack to bring mm reiser4 back to vanilla
> >>cd /usr/src/linux
> >>for i in `grep reiser4 ../broken-out/series`; do
> >>	patch -p1 < ../broken-out/$i;
> >>done
> >>
> >>I've attached one patch of my own that makes it compile properly --
> >>apply after you run the script above.

-- 
Pat Double, pat@patdouble.com
"In the beginning God created the heaven and the earth."

Re: reiser4 performance

[David Masover]

Pat Double wrote:
> Actually I did make it public, hit the wrong command on my mail client ;)
> 
> I did not try the -mm kernel (latest patches is for -mm5 IIRC), I use software 
> suspend 2 and it does not apply to the 2.6.12.x-mm series. Except for this 
> problem reiser4 has worked great for me. Since I use a single partition and 
> '/' does not get modified much I copied all my data over, rebuilt the 
> filesystem, and then started using it. I have not discovered any problems, 
> and the filesystem is quite fast.

That's with the mm reiser4, or the reiser4-for-2.6?

Glad to hear it works with Suspend2.  That's going to be the next thing 
I try, once my system is back up to speed.  I'm on Gentoo, so 
understandably it takes awhile to get back up to speed, Godlike amd64 
speeds notwithstanding.

Re: reiser4 performance

[Pat Double]

On Tuesday 09 August 2005 09:32 pm, David Masover wrote:
> Pat Double wrote:
> > Actually I did make it public, hit the wrong command on my mail client ;)
> >
> > I did not try the -mm kernel (latest patches is for -mm5 IIRC), I use
> > software suspend 2 and it does not apply to the 2.6.12.x-mm series.
> > Except for this problem reiser4 has worked great for me. Since I use a
> > single partition and '/' does not get modified much I copied all my data
> > over, rebuilt the filesystem, and then started using it. I have not
> > discovered any problems, and the filesystem is quite fast.
>
> That's with the mm reiser4, or the reiser4-for-2.6?
>
> Glad to hear it works with Suspend2.  That's going to be the next thing
> I try, once my system is back up to speed.  I'm on Gentoo, so
> understandably it takes awhile to get back up to speed, Godlike amd64
> speeds notwithstanding.

I used the reiser4-for-2.6 patches. Before the 2.6.12 patches were available I 
tried the -mm patches from reiser4-for-2.6 which applied cleanly. When 2.6.12 
recently I tried those with the same results. I did not try the -mm kernel 
sources because even if they worked flawlessly it would be no help to me. 
Suspend 2 is more important to me than reiser4. Shutdown in 30 seconds, 
startup in 30 seconds is more useful to me.

-- 
Pat Double, pat@patdouble.com
"In the beginning God created the heaven and the earth."

Re: reiser4 performance

[PFC]

> So for most webserver cases, FS speed doesn't matter. For the few
> cases where it does, locality is usually fairly good... so who cares
> if the new FS is 2x faster, when it is still 200x slower than ram. Add
> ram.

	But Reiser4 helps stuffing more files into the cache.
	It also helps when many people concurrently download (or upload) large  
files. Its streaming performances are very good.