From: "Bill C. Riemers" <docbill@freeshell.org>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Ensuring data is written to disk
Date: Mon, 7 Aug 2006 12:14:53 -0400 [thread overview]
Message-ID: <23bcb8700608070914w3c6402a4q99435e657b38dfbe@mail.gmail.com> (raw)
In-Reply-To: <44D73C0C.5010205@armiento.net>
[-- Attachment #1: Type: text/plain, Size: 3200 bytes --]
I was talking to a friend at Red Hat. He says what they suggest using ext3,
but putting the journal file small separate internal SCSI drive.... If you
do so you will get far better performance and reliability than from
reiserfs.
Bill
On 8/7/06, R. Armiento <reply-2006@armiento.net> wrote:
>
>
> Jens Axboe wrote:
> > On Tue, Aug 01 2006, Jamie Lokier wrote:
> >> Should we change to only reiserfs and expect fsync() to commit data
> >> reliably only with that fs? I realise this is a lot of difficult
> >> questions, that apply to more than just Qemu...
> >
> > Yes, reiser is the only one that works reliably across power loss with
> > write back caching for the journal commits as well as fsync guarantees.
>
> So, just to get this further clarified:
>
> Lets assume this typical website setup: HARDWARE: commodity SATA/PATA;
> drive cache is not battery backed up. HOST OS: late Linux 2.6 kernel
> (e.g. 2.6.15), directly, on top of host, a recent version of database
> software (e.g. MySQL 5.1). Running in ~ 'production'.
>
> Now, if I understand the foregoing discussion: the *only* way of running
> this setup with 'full' transactional guarantees on power loss, without
> having to change/patch the Linux kernel, is to turn off write-caching?
> And that severely decreases performance.
>
> To reiterate the foregoing discussion: fsync in ext3 only goes to the
> drive cache. ResiserFS v3, which is included in the kernel, does not
> guarantee data integrity on power loss. Reiser4 requires a kernel patch
> that the developers do not yet recommend for production use, see e.g.
> http://www.namesys.com/download.html . Furthermore (if I am not mislead)
> the XFS or JFS versions included in the kernel does not guarantee data
> integrity on power loss (Please reply and prove me wrong, even flames
> are welcome :). Hence, the best bet is Jamie Lokier's one line ext3
> patch, see:
> http://lists.gnu.org/archive/html/qemu-devel/2006-08/msg00032.html
> and then run ext3 in fully journaled mode (add data=journal to the mount
> options). In the 'unusual' case where it is enough with just database
> integrity, but acceptable that transactions may disappear on power loss,
> one can run ext3 in default mode.
>
> This is somewhat surprising to me, given claims of data integrity made
> by both ext3 and MySQL documentation.
>
> And then, on top of this, if one instead runs the database in a QEMU
> with a late Linux 2.6 kernel, one are just making data-loss more likely,
> right? So QEMU is in no way to blame for any of this.
>
> For people following this discussion (perhaps suitable for QEMU docs):
> To disable write-caching on HOST and GUEST os:es; Make sure
> hdparm -W0 [device]
> is run each bootup. On Debian/Ubuntu you do this by editing
> /etc/hdparm.conf
> and uncomment the line:
> write_cache = off
> However, this severely decreases performance. Also note: in MySQL the
> MyISAM table type still does not guarantee no data loss; you need innoDB
> for that.
>
> Best regards,
> Rickard
>
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>
[-- Attachment #2: Type: text/html, Size: 3966 bytes --]
next prev parent reply other threads:[~2006-08-07 16:14 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-08-01 0:11 [Qemu-devel] Ensuring data is written to disk Armistead, Jason
2006-08-01 10:17 ` Jamie Lokier
2006-08-01 10:45 ` Jens Axboe
2006-08-01 14:17 ` Jamie Lokier
2006-08-01 19:05 ` Jens Axboe
2006-08-01 21:50 ` Jamie Lokier
2006-08-02 6:51 ` Jens Axboe
2006-08-02 13:28 ` Jamie Lokier
2006-08-02 15:56 ` Bill C. Riemers
2006-08-07 13:11 ` R. Armiento
2006-08-07 16:14 ` Bill C. Riemers [this message]
2006-08-07 18:13 ` Thomas Steffen
2006-08-08 2:37 ` R. Armiento
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=23bcb8700608070914w3c6402a4q99435e657b38dfbe@mail.gmail.com \
--to=docbill@freeshell.org \
--cc=qemu-devel@nongnu.org \
/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;
as well as URLs for NNTP newsgroup(s).