Re: [PATCH 0/4] Fiemap, an extent mapping ioctl - round 2

[Anton Altaparmakov <aia21@cam.ac.uk>]

On Sat, 5 Jul 2008, Jamie Lokier wrote:
> Anton Altaparmakov wrote:
> > Any application that calls fiemap and then goes and reads or writes
> > those blocks on disk is totally brain damaged and should be sent to
> > bitrot hell.  fiemap is about information not about direct access to
> > disk by user space.
> 
> So why FIEMAP_EXTENT_NO_DIRECT "Direct access to the data in this
> extent is illegal or will have undefined results" in the patches?

Because sadly there are some applications with insane requirements. lilo 
is one example and swap files in the kernel is another example.  )-:

I think this is still the wrong way to do it and grub is a better answer 
for the problem lilo has and the kernel swap could just do O_DIRECT writes 
(though file system re-entry and locking will be a problem that will need 
solving somehow) but those applications exist already and given it is a 
one-bit flag to make them know whether it is relatively safe to do dirct 
access we mighst as well have it...  I mean if you make the kernel image 
only writable by the root user, and you assume the root user is not going 
to modify the file without re-running lilo then doing direct read from 
disk is fine as long as the file system does not do online defragmentation 
or anything other block moving about operations.  After all that is how 
lilo works now and it is what causes the machine to fail to boot if you 
replace the kernel image with a new kernel and do not re-run lilo...  It 
doesn't change the fact that I think it is a crazy thing to do.  And on 
some file systems the NO_DIRECT flag would be set for all files (because 
they perform online deframentation) and then things like lilo and kernel 
swap would know that they cannot work on those file systems so given we 
know people will use the interface for direct access even though it is an 
evil thing to do we should IMHO have the flag to make it a little safer 
for them to do it.

Best regards,

	Anton
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer, http://www.linux-ntfs.org/