]> CyberLeo.Net >> Repos - FreeBSD/FreeBSD.git/commit
After a crash, a file that extends into indirect blocks may end up
authormckusick <mckusick@FreeBSD.org>
Mon, 25 Feb 2019 21:58:19 +0000 (21:58 +0000)
committermckusick <mckusick@FreeBSD.org>
Mon, 25 Feb 2019 21:58:19 +0000 (21:58 +0000)
commit7b71e80a0f777234f70811f99b76bdd5950208c1
tree7ccbacf263cde50d88aae9e36a7a6fed7dad8103
parent53353090d004f1a8a1297ece323f669f50042621
After a crash, a file that extends into indirect blocks may end up
shorter than its size resulting in a hole as its final block (which
is a violation of the invarients of the UFS filesystem).

Soft updates will always ensure that the file size is correct when
writing inodes to disk for files that contain only direct block
pointers. However soft updates does not roll back sizes for files
with indirect blocks that it has set to unallocated because their
contents have not yet been written to disk. Hence, the file can
appear to have a hole at its end because the block pointer has been
rolled back to zero when its inode was written to disk. Thus,
fsck_ffs calculates the last allocated block in the file. For files
that extend into indirect blocks, fsck_ffs checks for a size past
the last allocated block of the file and if that is found, shortens
the file to reference the last allocated block thus avoiding having
it reference a hole at its end.

Submitted by: Chuck Silvers <chs@netflix.com>
Tested by:    Chuck Silvers <chs@netflix.com>
MFC after:    1 week
Sponsored by: Netflix
sbin/fsck_ffs/fsck.h
sbin/fsck_ffs/globs.c
sbin/fsck_ffs/pass1.c
sbin/fsck_ffs/setup.c
sbin/fsdb/fsdb.c
sys/ufs/ffs/ffs_alloc.c
sys/ufs/ffs/fs.h