On Mon, Jan 6, 2020 at 5:40 PM Amir Goldstein <amir73il@xxxxxxxxx> wrote: > > On Mon, Jan 6, 2020 at 9:26 AM Sitsofe Wheeler <sitsofe@xxxxxxxxx> wrote: > > > > At Linux Plumbers 2019 Dr Richard Hipp presented a talk about SQLite > > (https://youtu.be/-oP2BOsMpdo?t=5525 ). One of the slides was titled > > "Things to discuss" > > (https://sqlite.org/lpc2019/doc/trunk/slides/sqlite-intro.html/#6 ) > > and had a few questions: > > > [...] > > > > However, there were even more questions in the briefing paper > > (https://sqlite.org/lpc2019/doc/trunk/briefing.md and search for '?') > > that couldn't be asked due to limited time. Does anyone know the > > answer to the extended questions and whether the the above is right > > deduction for the questions that were asked? > > > > As Jan said, there is a difference between the answer to "what is the > current behavior" and "what are filesystem developers willing to commit > as behavior that will remain the same in the future", but I will try to provide > some answers to your questions. > > > 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...), Bah! scratch that. The statement is generally not true. Due to delayed allocation with xfs/ext4 you are much more likely to find the extended areas contain all zeroes. The only guaranty AFAIK is that with truncate+extend sequence, you won't find the old data in the re-extended area. Thanks, Amir.
