On Jun 28, 2018, at 4:12 PM, Theodore Y. Ts'o <tytso@xxxxxxx> wrote: > > On Thu, Jun 28, 2018 at 01:55:49PM -0600, Andreas Dilger wrote: >> On Jun 28, 2018, at 7:59 AM, Lukas Czerner <lczerner@xxxxxxxxxx> wrote: >>> >>> We do not allow initialized blocks to exist past i_size as this could >>> lead to stale data exposure. >> >> I don't think this is any more dangerous than uninitialized bytes beyond >> i_size in the same block, or as a hole in the middle of the file exposing >> stale data. That is to say, there is some risk, but not any worse. The >> converse is true also - extendiy,ng i_size to the end of the allocated blocks >> will not only expose that data, but in some cases make applications think >> the file is corrupted because there are now NULs at the end of the file. > > I believe what Lukas is referring to is the fact that historically, > ext2, ext3, and ext4 in the nodelalloc case used i_size as the > interlock to make sure we don't end up exposing stale data. With the > advent of punch hole functionality, life gets interesting so we have > one set of mechanisms for interlocking between buffered and direct I/O > for truncate, and different one for punch hole. > > So the kernel should never create intialized blocks past i_size. I've > done some quick checks, and this appears to be correct. That's true for stock ext4, but as I mentioned in my other email, Lustre will allocate up to the PAGE_SIZE boundary because the RDMA will overwrite the whole page regardless of where i_size is, which results in blocks being allocated beyond i_size for PAGE_SIZE > blocksize. While that is not a typical configuration (we always format with 4KB blocksize, and typically run x86 servers), there are a few sites that have SPARC servers, so this patch is to accommodate them. Cheers, Andreas
Attachment:
signature.asc
Description: Message signed with OpenPGP
