lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150622164804.GA9393@lst.de>
Date:	Mon, 22 Jun 2015 18:48:04 +0200
From:	Christoph Hellwig <hch@....de>
To:	Jeff Moyer <jmoyer@...hat.com>
Cc:	Dan Williams <dan.j.williams@...el.com>,
	Jens Axboe <axboe@...nel.dk>,
	"linux-nvdimm@...ts.01.org" <linux-nvdimm@...1.01.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Linux ACPI <linux-acpi@...r.kernel.org>,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>,
	Ingo Molnar <mingo@...nel.org>
Subject: Re: [PATCH 14/15] libnvdimm: support read-only btt backing devices

On Mon, Jun 22, 2015 at 12:42:44PM -0400, Jeff Moyer wrote:
> OK, add torn sector detection/recovery to that statement, then.  More
> importantly, do you agree with the sentiment or not?

I think we're getting on a very slipper slope if we think about
application here.  Buffered I/O application must deal with torn
writes at any granulairty anyway, e.g. fsync + rename is the
only thing they can rely on right now (I actually have software O_ATOMIC
code to avoid this, but that's another story).

Direct I/O using application can make assumption if they know the sector
size, and we must have a way for them to be able to see our new
"subsector sector size".  And thos application are few inbetween but
also important so needing special cases for them is fine.  Although those
are the most likely ones to take advantage of byte addressing anyway.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ