Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
PostgreSQL 9.3 beta: Federated databases and more
LWN.net Weekly Edition for May 9, 2013
(Nearly) full tickless operation in 3.10
Even if an application has root privileges, a bug in it (even just not zeroing out padding in a structure) may result in an accidental leak of data from a totally unrelated file to a remote client.
The only sensible variant is zeroing blocks from deleted files in the background and only using those scrubbed blocks.
Allocating uninitialized file blocks
Posted Apr 19, 2012 15:35 UTC (Thu) by jzbiciak (✭ supporter ✭, #5246)
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?
Posted Apr 19, 2012 19:28 UTC (Thu) by nybble41 (subscriber, #55106)
Posted Apr 20, 2012 5:41 UTC (Fri) by jzbiciak (✭ supporter ✭, #5246)
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.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds