reiser4 status (correction)

reiser4 status (correction)

[Hans Reiser]

Well, it seems we still aren't quite as stable as we were 6 months ago 
(the new reduced cpu usage code was extensive, as was the VFS change 
code), and we know of a bug we can reproduce using our standard tests.  
Also, it seems we can oops when a particular program is run to consume 
all memory (thanks Jate for finding it).  Hopefully things will be more 
stable next week....  Us developers are using the new code on our 
workstations without problem though.

On a more positive note, Reiser4.1 is getting closer to release....  It 
is working fine for the developer coding it, and we are scheduling code 
reviews for it and defining migration paths, etc.  Hopefully in 2 months 
it will ship.

The big issue with 4.1 is that we are having to deal with all the issues 
of REALLY allowing users to change default plugins, etc., and finding we 
missed details.  We will say more later.

Thanks for your patience,

Hans

Re: reiser4 status (correction)

[Hans Reiser]

David Masover wrote:

> Hans Reiser wrote:
>
>> On a more positive note, Reiser4.1 is getting closer to release....
>
>
> Good news!  But it's been awhile since I've followed development, and
> the homepage seems out of date (as usual).  Where can I find a list of
> changes since v4?
>
> By "out of date", I mean things like this:
>
> "Reiser4.1 will modify the repacker to insert controlled "air holes",
> as it is well known that insertion efficiency is harmed by overly
> tight packing."

Sigh, no, the repacker will probably be after 4.1....

The list of tasks for zam looks something like:

fix bugs that arise

debug read optimization code (CPU reduction only, has no effect on IO),
1 week est.  (would be nice if it was less)

review compression code 1 day per week until it ships.

fix fsync performance (est. 1 week of time to make post-commit writes
asynchronous, maybe 3 weeks to create fixed-reserve for write twice
blocks, and make all fsync blocks write twice)

write repacker (12 weeks).

I am not sure that putting the repacker after fsync is the right choice....

The task list for vs looks like:

* fix bugs as they arise.

* fix whatever lkml complains about that either seems reasonable, or
that akpm agrees with.

* Help edward get the compression plugins out the door.

* Improve fsck's time performance.

* Fix any V3 bugs that Chris and Jeff don't fix for us.  Which reminds
me, I need to check on whether the 90% full bug got fixed....

Re: reiser4 status (correction)

[David Masover]

Hans Reiser wrote:

> I am not sure that putting the repacker after fsync is the right choice....

Does the repacker use fsync?  I wouldn't expect it to.

Does fsync benefit from a properly packed FS?  Probably.

Also, while I don't expect anyone else to be so bold, there is a way 
around fsync performance:  Disable it.  Patch the kernel so that any 
fsync call from userspace gets ignored, but lie and tell them it worked. 
  Basically:

  asmlinkage long sys_fsync(unsigned int fd)
  {
-       return do_fsync(fd, 0);
+       return 0;       // do_fsync(fd, 0);
  }

In order to make this sane, you should have backups and an Uninterrupted 
Power Supply.  In the case of a loss of power, the box should notice and 
immediately sync, then either shut down or software suspend.  Any UPS 
battery should be able to handle the amount of time it takes to shut the 
system off.

Since anything mission critical should have backups and a UPS anyway, 
the only problem left is what happens if the system crashes.  But system 
crashes are something you have to plan for anyway.  Disks fail -- stuff 
happens.  RAID won't save you -- the RAID controller itself will 
eventually fail.

So suppose you're running some very critical server -- for now, chances 
are it's running some sort of database.  In this case, what you really 
want is database replication.  Have at least two servers up and running, 
and consider the transaction complete not when it hits the disk, but 
when all running servers acknowledge the transaction.  The RAM of two 
boxes should be safer than the disk of one.

What about a repacker?  The best I can do to hack around that is to 
restore the whole box from backup every now and then, but this requires 
the box to be down for awhile -- it's a repacker, but not an online one. 
  In this case, the solution would be to have the same two servers 
(replicating databases), and bring first one down, and then the other.

That would make me much more nervous than disabling fsync, though, 
because now you only have the one server running, and if it goes down... 
  And depending on the size of the data in question, this may not be 
feasable.  It seems entirely possible that in some setups like this, the 
only backup you'd be able to afford would be in the form of replication.

In my own personal case, I'd prefer the repacker to tuning fsync.  But 
arguments could be made for both.

Re: reiser4 status (correction)

[Mike Benoit]

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

On Fri, 2006-07-21 at 02:44 -0600, Hans Reiser wrote:
> fix fsync performance (est. 1 week of time to make post-commit writes
> asynchronous, maybe 3 weeks to create fixed-reserve for write twice
> blocks, and make all fsync blocks write twice)
> 
> write repacker (12 weeks).
> 
> I am not sure that putting the repacker after fsync is the right choice....
> 

Tuning fsync will fix the last wart on Reiser4 as far as benchmarks are
concerned won't it? Right now Reiser4 looks excellent on the benchmarks
that don't use fsync often (mongo?), but last I recall the fsync
performance was so poor it overshadows the rest of the performance. It
would also probably be more useful to a much wider audience, especially
if Namesys decides to charge for the repacker.

ReiserV3 is used on a lot of mail and squid proxy servers that deal with
many small files, and these work loads usually call fsync often. My
guess is that ReiserV3 users are the most likely to migrate to Reiser4,
because they already know the benefits of using a "Reiser" file system.
But neglecting fsync performance will just put a sour taste in their
mouth. 

On top of that, I don't see how a repacker would help these work loads
much as the files usually have a high churn rate. Packing them would
probably be a net loss as the files would just be deleted in 24hrs and
replaced by new ones.

Very few people will (or should) disable fsync as David suggests, I
don't see that as a solution at all, even if it is temporary.

-- 
Mike Benoit <ipso@snappymail.ca>

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

Re: reiser4 status (correction)

[David Masover]

Mike Benoit wrote:

> Tuning fsync will fix the last wart on Reiser4 as far as benchmarks are
> concerned won't it? Right now Reiser4 looks excellent on the benchmarks
> that don't use fsync often (mongo?), but last I recall the fsync
> performance was so poor it overshadows the rest of the performance. It
> would also probably be more useful to a much wider audience, especially
> if Namesys decides to charge for the repacker.

If Namesys does decide to charge for the repacker, I'll have to consider 
whether it's worth it to pay for it or to use XFS instead.  Reiser4 
tends to become much more fragmented than most other Linux FSes -- 
purely subjective, but probably true.

> ReiserV3 is used on a lot of mail and squid proxy servers that deal with
> many small files, and these work loads usually call fsync often.
[...]
> But neglecting fsync performance will just put a sour taste in their
> mouth. 

So will neglecting fragmentation, only worse.  At least fsync is slow up 
front.  Fragmentation will be slow much farther in, when the mailserver 
has already been through one painful upgrade.  Charging for the repacker 
just makes it worse.

> On top of that, I don't see how a repacker would help these work loads
> much as the files usually have a high churn rate. Packing them would
> probably be a net loss as the files would just be deleted in 24hrs and
> replaced by new ones.

Depends.  Some will, some won't.  My IMAP server does have a lot of 
churning, but there's also the logs (which stay for at least a month or 
two before they rotate out), and since it's IMAP, I do leave quite a lot 
of files alone.

v3 is also used on a lot of web servers, at least where I used to work 
-- some areas will be changing quite a lot, and some areas not at all. 
Changing a lot means fragmentation will happen, not changing at all 
means repacking will help.

These issues may be helped by partitioning, if you know how you're going 
to split things up.  But then, how do you partition in the middle of a 
squid server?  A lot of people visit the same sites every day, checking 
for news, but that means plenty of logos, scripts, and other things 
won't change -- but plenty of news articles will change every couple hours.

> Very few people will (or should) disable fsync as David suggests, I
> don't see that as a solution at all, even if it is temporary.

I guess the temporary solution is to incur a pretty big performance hit. 
  But it comes back to, which is more of a performance problem, fsync or 
fragmentation?

And I really would like to hear a good counter-argument to the one I've 
given for disabling fsync.  But even if we assume fsync must stay, do we 
have any benchmarks on fragmentation versus fsync?

But maybe it's best to stop debating, since both will be done 
eventually, right?

Re: reiser4 status (correction)

[Hans Reiser]

Mike Benoit wrote:

>
>On top of that, I don't see how a repacker would help these work loads
>much as the files usually have a high churn rate. 
>
I think Reiserfs is used on a lot more than squid servers.  For them,
80% of files don't move for long periods of time is the usual industry
statistic....