| |||||||||||||
Many more words on volatile rangesMany more words on volatile rangesPosted Nov 7, 2012 6:29 UTC (Wed) by dlang (✭ supporter ✭, #313)In reply to: Many more words on volatile ranges by foom Parent article: Many more words on volatile ranges
This is a new way to punch holes in files, but the concept of files with holes in them is far from new.
This leads to a couple obvious answers
> What sorts of controls over who can mark data like that will there be? Can it cause a security issue for data to disappear in the middle of a file unexpectedly? Maybe clearing volatile-ness on file ownership or permissions change fixes that?
Tie this to the ability to modify/truncate the file and you are not adding any new possibilities, just new ways to trigger the possibilities (someone who can modify the file can truncate it, write a new file missing some data, etc)
> How can I tell how much space is used by such data?
the same way you would find out how much space is used by other sparse files today.
(Log in to post comments)
Many more words on volatile ranges Posted Nov 8, 2012 3:04 UTC (Thu) by foom (subscriber, #14868) [Link]
The new thing isn't the holes after they've been punched, it's that holes can be pre-marked, such that they will be punched by the kernel some undetermined amount of time in the future. Perhaps 2 months later, after rebooting 20 times, and plugging the disk into another computer.
> Tie this to the ability to modify/truncate the file and you are not adding any new possibilities, just new ways to trigger the possibilities (someone who can modify the file can truncate it, write a new file missing some data, etc)
But without taking extra preventative measures, the ability to ever once *have* *had* permission to modify a file might then result in the ability to modify the file (by zeroing out some blocks) any arbitrary time in the future.
> the same way you would find out how much space is used by other sparse files today.
But these new files aren't sparse immediately; volatile data does use up actual space, until it gets dropped on the floor. That's a brand new type of thing.
Many more words on volatile ranges Posted Nov 8, 2012 7:47 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
> But without taking extra preventative measures, the ability to ever once *have* *had* permission to modify a file might then result in the ability to modify the file (by zeroing out some blocks) any arbitrary time in the future.
remember that permission checks are only made when the file is opened, so even without this you could hold the filehandle open and erase blocks at any time.
Yes, this can now happen even after the program has exited (more below)
> But these new files aren't sparse immediately; volatile data does use up actual space, until it gets dropped on the floor. That's a brand new type of thing.
you can do one of two things by default (and either one is defensible)
1. show the size as it currently occupies disk space
2. show the size as if the holes had been reclaimed by the filesystem
I would probably do #1, because with sparse files, you already have a situation where the file size on disk can change significantly, so this is not that different.
to cover the rest of the first problem, and the corner cases of the second problem, there will need to be a utility to report on what's been tagged as being volatile, but that tool will probably just be needed for odd, corner cases. The existing options for dealing with sparse files should cover the 'normal' needs
|
|||||||||||||