From: David Masover <ninja@slaphack.com>
To: Hans Reiser <reiser@namesys.com>
Cc: reiserfs-list@namesys.com, LKML <linux-kernel@vger.kernel.org>,
Alexander Zarochentcev <zam@namesys.com>,
vs <vs@thebsh.namesys.com>
Subject: Re: reiser4 status (correction)
Date: Fri, 21 Jul 2006 14:13:04 -0500 [thread overview]
Message-ID: <44C12740.1040203@slaphack.com> (raw)
In-Reply-To: <44C093D2.1040703@namesys.com>
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.
next prev parent reply other threads:[~2006-07-25 19:38 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-07-20 21:59 reiser4 status (correction) Hans Reiser
[not found] ` <44C043B5.3070501@slaphack.com>
2006-07-21 8:44 ` Hans Reiser
2006-07-21 19:13 ` David Masover [this message]
2006-07-21 20:41 ` Mike Benoit
2006-07-21 21:06 ` David Masover
2006-07-22 0:49 ` Hans Reiser
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=44C12740.1040203@slaphack.com \
--to=ninja@slaphack.com \
--cc=linux-kernel@vger.kernel.org \
--cc=reiser@namesys.com \
--cc=reiserfs-list@namesys.com \
--cc=vs@thebsh.namesys.com \
--cc=zam@namesys.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox