public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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.

  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