linux-ext4 - Re: [PATCH v3 0/3] Add XIP support to ext4

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: <20131220193455.GA6912@thunk.org>
Date:	Fri, 20 Dec 2013 14:34:55 -0500
From:	Theodore Ts'o <tytso@....edu>
To:	Matthew Wilcox <matthew@....cx>
Cc:	Dave Chinner <david@...morbit.com>,
	Matthew Wilcox <matthew.r.wilcox@...el.com>,
	linux-ext4@...r.kernel.org, linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH v3 0/3] Add XIP support to ext4

On Fri, Dec 20, 2013 at 11:17:31AM -0700, Matthew Wilcox wrote:
> 
> Maybe.  We have a tension here between wanting to avoid unnecessary
> writes to the media (as you say, wear is going to be important for some
> media, if not all) and wanting to not fragment files (both for extent
> tree compactness and so that we can use PMD or even PGD mappings if the
> stars align).  It'll be up to the filesystem whether it chooses to satisfy
> the get_block request with something prezeroed, or something that aligns
> nicely.  Ideally, it'll be able to find a block of storage that does both!
> 
> Actually, I now see a second way to read what you wrote.  If you meant
> "we can map in ZERO_PAGE or one of its analogs", then no.  The amount
> of cruft that optimisation added to the filemap_xip code is horrendous.
> I don't think it's a particularly common workload (mmap a holey file,
> read lots of zeroes out of it without ever writing to it), so I think
> it's far better to allocate a page of storage and zero it.

It seems that you're primarily focused about allocated versus
unallocated blocks, and what I think Dave and I are trying to point
out is the distinction between initialized and uninitialized blocks
(which are already allocated).

So I was thinking about the case where the blocks were already
allocated and mapped --- so we have a logical -> physical block
mapping already established.  However, if the blocks were allocated
via fallocate(2), so they are unallocated, although they will be
well-aligned.

Which means that if you pre-zero at read time, at that point you will
be fragmenting the extent tree, and the blocks are already
well-aligned so it's in fact better to fault in a zero page at read
time when we are dealing with an allocated, but not-yet-initialized
block.

Also, one of the ways which we handle fragmentation is via delayed
allocation.  That is, we don't make the allocation decision until the
last possible second.  We do lose this optimization for direct I/O,
since that's part of the nature of the beast --- but there's no reason
not to have it for XIP writes --- especially if the goal is to be able
to support persistent memory storage devices in a first class way,
instead of a one-off hack for demonstration purposes....

	     	     	      		    - Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html