On Saturday 22 April 2006 03:27, Vitaly Wool wrote:
> 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' :):)
A lot of what happens when you do this will depends more on the
UNIX/Posix filesystem calls than Yaffs.
If you hold the new data in memory, and open the old file with
O_TRUNC, then write out the update, then the old data is 'lost'
from the filesystem on the open(2) call. This frees the storage,
so it can be used to hold new data; but leaves you with a big
window without data.
Under the covers a large write is the same as a sequence of
smaller writes, and Yaffs performs the write operation in chunk
(nand-page) sized steps.
An update that over-writes the existing file, without O_TRUNC,
will replace the old chunks (nand-pages) with new ones,
containing the updated data (one-by-one in a sequence). If Yaffs
runs low on chunks, the garbage collector will erase a block
that contained old data. This gets us to the question of
'reserve', and perhaps Charles can tell us how the reserve is
managed. I can imagine getting into a corner, when performing
an update such as this, where there is insufficient 'elbow' room
for the garbage collector to free up a complete block. In which
case, somewhere along the sequence of chunk/page writes, it will
fail and return a partial write (large buffer) or a failed write
(small buffer). Now you are left with new data at the start of
the file and old data at the end. Perhaps this is OK for your
application(?).
On Unix, the semantics of rename(2) help solve this common
problem. Write out the new data to a new file (requiring twice
the NAND space in the process); close the old file; then rename
new file to the name of the old file. If rename(2) fails to
fully complete (due to powerdown for example), you either have
two files, the old and the new; or you have the new, and the old
one is found in lost+found (unless it had multiple links). If
rename(2) succeeds, the new file takes the place of old, the old
file is unlinked and its storage is released ready for the
garbage collector to gobble up. The application will need to
'reopen' the new file.
-imcd
(text/plain)