Allocating uninitialized file blocks

Posted Apr 19, 2012 15:35 UTC (Thu) by jzbiciak (guest, #5246)
In reply to: Allocating uninitialized file blocks by slashdot
Parent article: Allocating uninitialized file blocks

How is this at all different than just opening up the device node associated with the partition? If you're root, what's stopping you?

As Ted Ts'o suggested, if a process has the capability to do raw I/O, why not let it see raw disk blocks occasionally? You've already given it permission to do low level I/O in spite of a filesystem, so what's the harm in letting it stale blocks within a filesystem?

Allocating uninitialized file blocks

Posted Apr 19, 2012 19:28 UTC (Thu) by nybble41 (subscriber, #55106) [Link] (1 responses)

The problem is that while a root process or one with raw I/O capabilities can see those blocks itself, it wouldn't usually write them out to a file which other users could read. However, if a root process allocates space for a file readable by non-root processes, and that space remains uninitialized, the other processes will have access to the former contents of those blocks.

Allocating uninitialized file blocks

Posted Apr 20, 2012 5:41 UTC (Fri) by jzbiciak (guest, #5246) [Link]

Well, this new fallocate() feature is explicit. It's not like we're suddenly changing the semantics of holes in files. It's really about policy vs. mechanism. We need to ask if this is a useful mechanism, and if so, can user space use it safely if it adopts appropriate polices?

The definition of "appropriate policy" depends entirely on the usage scenario and security requirements of the system and application. A DVR disk that has nothing but video files on it won't leak anything interesting, so this fallocate() mode may be perfectly suited to it, for example, assuming a bittorent-style scattered download.

All that said, this new mode does need to prove its usefulness. If the performance issue is unique to ext4, then it's probably better to just fix ext4.