On Thu, Feb 01, 2018 at 09:40:03PM -0500, Theodore Ts'o wrote: > On Fri, Feb 02, 2018 at 10:04:15AM +1100, Dave Chinner wrote: > > I think putting valid data beyond EOF is going to be problematic for > > many filesystems. Getting things like truncate right are hard enough > > without having to special case a bunch of new functionality that > > specifically allows IO access beyond EOF. Indeed, how does "truncate > > isize but leave special data behind" work and what's the userspace > > API to drive it? And how does it interact with all the page cache > > code that checks for page->index beyond EOF to detect a truncated > > page that should not be accessed? > > This isn't an issue because once fs-verity protection is enabled, the > file becomes immutable. yes, but we still have to do some kind of "truncate but not truncate" to change the file size leaving the data beyond EOF behind. What's the API for this? > That is, you can delete the file, but you > can't modify it afterwards --- so you don't have to truncate it. Sure, but.... > We don't actually want userspace to be able to access pages beyond > i_size via read(2) or mmap(2), so I don't believe this to be a > problem. It's only kernel code that needs to access the pages via > find_get_page. So you're expecting to short circuit page cache read paths to ignore that the page is beyond EOF. i.e. we've got to screw with the truncate race detection code in the generic read code to make this work? This really seems like a one-way process to me - we can't back up a filesystem that has integrity information stored beyond EOF, right? What other common filesystem tools are going to break (or break integrity checking) because they don't understand that there is valid data stored in "unused" extents beyond EOF? Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx
