Bug 106107 - [ufs] left-over fsck_snapshot after unfinished background fsck if filesystem clean
Summary: [ufs] left-over fsck_snapshot after unfinished background fsck if filesystem ...
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 6.1-RELEASE
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-bugs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-12-01 03:20 UTC by Andrej Binder
Modified: 2021-07-27 19:26 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andrej Binder 2006-12-01 03:20:10 UTC
Whenever fsck is run in background mode, a file called fsck_snapshot gets created in the .snap directory on the checked volume. Fsck then runs its check on this file instead of the live filesystem. Filesystem snapshots (which fsck_snapshot essentially is) are designed to persist over mounts and reboots thus if fsck does not terminate properly for some reason (hard reboot etc), the file gets left over.  This is partially solved on the next background fsck run (commonly just after the system reboots if the fs is marked dirty) since fsck overwrites the left over fsck_snapshot whit a new one and removes it when its done.

The prblem occours when you mark the filesystem clean before the next fsck background run (for example through fsck in singleuser mode). This way the fsck_snapshot file persists and possibly consumes most of the filesystem (depending on the state of the filesystem when the snapshot was made).

Fix: 

Implement a code (maybe into loader after the the fs is mounted) to check for left over fsck snapshots and remove them if appropriate.
How-To-Repeat: 1) run fsck in background mode
2) halt -qn before fsck finishes (or otherwise terminate it unproperly ... sigkill does not seem to work since fsck is in biord state)
3) boot into singleuser mode
4) fsck to mark the filesystem clean
5) reboot into normal mode and watch the file grow with every change on the live filesystem
Comment 1 Bruce Cran freebsd_committer 2010-04-03 11:55:14 UTC
Responsible Changed
From-To: freebsd-bugs->freebsd-fs

Over to maintainer(s).
Comment 2 Eitan Adler freebsd_committer freebsd_triage 2017-12-31 07:58:39 UTC
For bugs matching the following criteria:

Status: In Progress Changed: (is less than) 2014-06-01

Reset to default assignee and clear in-progress tags.

Mail being skipped
Comment 3 Graham Perrin 2021-07-21 17:17:31 UTC
Please, does this bug explain the clean-then-dirty behaviour that's observed in the following transcript? 

<https://lists.freebsd.org/archives/freebsd-current/att-0339/2021-07-16_00.53_typescript.txt>

First observed (and reproducible) whilst working with faulty hardware. 

Reproducible today with a new SSD.
Comment 4 Kirk McKusick freebsd_committer 2021-07-27 05:31:41 UTC
(In reply to Graham Perrin from comment #3)
Your transcript does not use snapshots, so this bug which is about snapshots does not apply to your transcript.

The update to the block counts should not have affected the file type, so it would appear that when the inode block with the updated count and size fields was written to disk, other parts of it were scrambled. This implies some kind of error in writing the inode block to the disk.
Comment 5 Graham Perrin 2021-07-27 19:26:01 UTC
(In reply to Kirk McKusick from comment #4)

Thank you. (I wondered whether there might be a shared underlying cause.)

I'll raise a separate bug report.