On Tue, Mar 28, 2006 at 11:00:56AM -0500, Stephen C. Tweedie wrote:
> Sorry, but you have to deal with that anyway. There is no guarantee
> that a page write is atomic.
Since this is the case, we really do not lose any guarantees by
allowing situations where eCryptfs does two page reads or writes on
the lower filesystem for one page read or write on the eCryptfs
filesystem. If we allow for this under some circumstances, I think we
have a good solution for the page alignment problem, balancing
correctness and performance needs. The idea is to make the common case
fast while making every case correct.
The first step will be to make eCryptfs operate on 4K-block chunks
rather than on PAGE_SIZE chunks. This should not be a very difficult
modification, and it will even result in faster performance on hosts
with page sizes over 4K, since unnecessary encryption and decryption
will be avoided. This is at least necessary to make eCryptfs files
movable between hosts with different page sizes at the moment.
Then, if the host has a page size of either 4K or 8K, we will make the
default header size 8K. This will cover, by default, all hosts where
the page size is either 4K or 8K (which is the vast majority); no page
straddling will occur, and so page reads and writes will be one-to-one
between the eCryptfs and the lower files. If the host's page size is
greater than 8K, then the header will, by default, occupy the host's
page size. This will take care of the page alignment problem for the
majority of the use case scenarios. The only time pages will not be
aligned is if a file is created on a host with a page size less than
or equal to 8K and then the file is transferred to a host with a page
size greater than 8K. In that case, two-to-one page reads and writes
will occur, causing a performance hit, but it will still work. In any
case, userspace tools can always convert the header to an appropriate
size for optimal performance if need be.
In future versions of eCryptfs, where the header data can span more
than 8K, then eCryptfs will spill over that header information onto
the end of the file, rewriting on truncate events, as previously
discussed in this thread. This will incur a performance hit on every
truncate event. Again, userspace tools (i.e., ecryptfstune) can resize
the header at the beginning of the file to store all of the data in
order to improve performance if need be. In any case, we anticipate
that header extent spill-over will be a rare event.
When HMAC support is enabled in future versions, the quantity of data
necessary to store the HMAC data may frequently be larger than 8K; we
can just make the header for HMAC-verified files something like 64K by
default then, and only very large files will require the header
information to spill over to the end of the file. The optimal header
size with HMAC turned on will need to be determined via analysis.
> Would it be possible simply to shift metadata to a subdir, so file
> foo has the header in .encfs/foo ? That may be a performance cost
> you don't want to bear, especially for small files, of course. If
> the header can be shrunk enough, xattrs might also be possible;
> although that has its own problems, such as compatibility with NFS
> etc.
Keeping the meta-data together with the data in the lower file has
always been a key feature of the eCryptfs filesystem. Divorcing the
crypto meta-data necessary to access the data for any given file
should be an absolute last resort. In any case, keeping groups of 4K
extents of header data in the front or on the end of the file does not
impose a significant degree of design or implementation complexity on
eCryptfs.
Thanks,
Mike
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
