Re: Questions about filesystems from SQLite author presentation

[Jan Kara <jack@suse.cz>]

On Mon 06-01-20 17:40:20, Amir Goldstein wrote:
> On Mon, Jan 6, 2020 at 9:26 AM Sitsofe Wheeler <sitsofe@gmail.com> wrote:
> > If a power loss occurs at about the same time that a file is being extended
> > with new data, will the file be guaranteed to contain valid data after reboot,
> > or might the extended area of the file contain all zeros or all ones or
> > arbitrary content? In other words, is the file data always committed to disk
> > ahead of the file size?
> 
> While that statement would generally be true (ever since ext3
> journal=ordered...),
> you have no such guaranty. Getting such a guaranty would require a new API
> like O_ATOMIC.

This is not quite true.

1) The rule you can rely on is: No random data in a file. So after a power
failure the state of the can be:
  a) original file state
  b) file size increased (possibly only partially), each block in the
     extended area contains either correct data or zeros.

There are exceptions to this for filesystems that don't maintain metadata
consistency on crash such as ext2, vfat, udf, or ext4 in data=writeback
mode. There the outcome after a crash is undefined...

> > If a write occurs on one or two bytes of a file at about the same time as a power
> > loss, are other bytes of the file guaranteed to be unchanged after reboot?
> > Or might some other bytes within the same sector have been modified as well?
> 
> I don't see how other bytes could change in this scenario, but I don't
> know if the hardware provides this guarantee. Maybe someone else knows
> the answer.

As Matthew wrote this boils down to whether the HW provides sector write
atomicity. Practically that seems to be the case.

> > Is it possible (or helpful) to tell the filesystem that the content of a particular file
> > does not need to survive reboot?
> 
> Not that I know of.
> 
> > Is it possible (or helpful) to tell the filesystem that a particular file can be
> > unlinked upon reboot?
> 
> Not that I know of.

Well, you could create the file with O_TMPFILE flag. That will give you
unlinked inode which will get just deleted once the file is closed (and
also on reboot). If you don't want to keep the file open all the time you
use it, then I don't know of a way.

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR