From: Howard Chu <hyc@symas.com>
To: Andy Rudoff <andy@rudoff.com>, Dan Williams <dan.j.williams@intel.com>
Cc: lsf-pc <lsf-pc@lists.linux-foundation.org>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
jmoyer <jmoyer@redhat.com>, david <david@fromorbit.com>,
Chris Mason <clm@fb.com>, Jens Axboe <axboe@kernel.dk>,
Bryan E Veal <bryan.e.veal@intel.com>,
Annie Foong <annie.foong@intel.com>
Subject: Re: [LSF/MM TOPIC] atomic block device
Date: Sat, 15 Feb 2014 10:29:18 -0800 [thread overview]
Message-ID: <52FFB1FE.9040300@symas.com> (raw)
In-Reply-To: <CABBL8ELycRzfyDGtKWk1nFySh9-a5Rh5uZXdgGEwMYHxCQzO3Q@mail.gmail.com>
Andy Rudoff wrote:
> On the other side of the coin, I remember Dave talking about this
> during our NVM discussion at LSF last year and I got the impression
> the size and number of writes he'd need supported before he could
> really stop using his journaling code was potentially large. Dave:
> perhaps you can re-state the number of writes and their total size
> that would have to be supported by block level atomics in order for
> them to be worth using by XFS?
If you're dealing with a typical update-in-place database then there's no
upper bound on this, a DB transaction can be arbitrarily large and any partial
write will result in corrupted data structures.
On the other hand, with a multi-version copy-on-write DB (like mine,
http://symas.com/mdb/ ) all you need is a guarantee that all data writes
complete before any metadata is updated.
IMO, catering to the update-in-place approach is an exercise in futility since
it will require significant memory resources on every link in the storage
chain and whatever amount you have available will never be sufficient.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
next prev parent reply other threads:[~2014-02-15 18:29 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-15 15:04 [LSF/MM TOPIC] atomic block device Dan Williams
2014-02-15 17:55 ` Andy Rudoff
2014-02-15 18:29 ` Howard Chu [this message]
2014-02-15 18:31 ` Howard Chu
2014-02-15 18:02 ` James Bottomley
2014-02-15 18:15 ` Andy Rudoff
2014-02-15 20:25 ` James Bottomley
2014-03-20 20:10 ` Jeff Moyer
[not found] ` <CABBL8E+r+Uao9aJsezy16K_JXQgVuoD7ArepB46WTS=zruHL4g@mail.gmail.com>
2014-02-15 21:35 ` Dan Williams
2014-02-17 8:56 ` Dave Chinner
2014-02-17 9:51 ` [Lsf-pc] " Jan Kara
2014-02-17 10:20 ` Howard Chu
2014-02-18 0:10 ` Dave Chinner
2014-02-18 8:59 ` Alex Elsayed
2014-02-18 13:17 ` Dave Chinner
2014-02-18 14:09 ` Theodore Ts'o
2014-02-17 13:05 ` Chris Mason
2014-02-18 19:07 ` Dan Williams
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=52FFB1FE.9040300@symas.com \
--to=hyc@symas.com \
--cc=andy@rudoff.com \
--cc=annie.foong@intel.com \
--cc=axboe@kernel.dk \
--cc=bryan.e.veal@intel.com \
--cc=clm@fb.com \
--cc=dan.j.williams@intel.com \
--cc=david@fromorbit.com \
--cc=jmoyer@redhat.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=lsf-pc@lists.linux-foundation.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.