lkml.org 
[lkml]   [2006]   [Jul]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: reiser4 status (correction)
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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2006-07-25 21:41    [W:0.676 / U:0.880 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site