On Saturday 22 April 2006 19:27, Vitaly Wool wrote:
> Hi Charles,
>
> Charles Manning wrote:
> >You will end up with a partial write. eg. If you have 500k free and you
> >attempt to write 1MB then 500k will be written and the write call will
> > return 500k.
> >
> >YAFFS keeps enough space in reserve to flush any in-flight internal cache
> > and flush file handles etc.
> >
> >What definitely will not happen is file structure getting corrupted.
>
> thanks! However I meant the following situation: suppose we've got 500k
> free, and we're trying to write a new version of 1M file (i. e. rewrite
> the old one). How will the filesystem handle this? I. e. will it refuse
> the write operation or grant it? If latter, what will happen if a power
> failure happens in the midst of the write (for instance, when 600k is
> written already -- there's not enough space to hold both the old and the
> new versions so how will the incomplete write be reverted?)
> OTOH, if there's enough space to hold both the old and the new versions,
> will the power pailure always be handled by the filesystem in such a way
> that retains the integrity of the file being written (i. e. either the
> old or the new version). I hope it will, but still being sure is better
> than thinking 'probably it will' :)

There's some confusion (and grey areas) here between transaction-based and log 
structureds fs.

A transaction-based fs will either accept or reject a whole write operation 
and if power is lost (or other failure), then the whole operation will be 
reversed.

A log structured fs (such as yaffs) does not provide the above guarantees 
unless it also claims to be transaction-based.

YAFFS is not transaction-bassed. If you interrupt part way through a write, 
then some of the write will happenand there is no mechanism to reverse this.

IMHO transaction safety is, perhaps, a nice thing, but is very difficult to 
implement effectively (and fully safely). It also hammers performance. A 
transaction based fs that I have investigated was significantly slower than 
its non-transaction-based incarnation and also did not manage to achieve 
transaction safety all of the time.

Transaction safety at a file level is often still not enough. For example, 
many databases need to write two or three files as a single transaction to be 
"sane" and a transaction-based fs will not guarantee that.

-- Charles