Re: [LSF/MM TOPIC] atomic block device

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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/
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux