> On 18. Sep 2018, at 16:39, J. Hannken-Illjes <hann...@eis.cs.tu-bs.de> wrote: > > >> On 18. Sep 2018, at 16:33, Manuel Bouyer <bou...@antioche.eu.org> wrote: >> >> On Tue, Sep 18, 2018 at 04:24:28PM +0200, J. Hannken-Illjes wrote: >>> There will be no copy-on-write to persistent snapshots so the snapshots >>> will contain garbage where the real file system writes data. >> >> Ha yes, of course. One could argue that if a systadmin boots a >> kernel with FFS_NO_SNAPSHOT he should know what he's doing. >> >> Maybe we could leave out the FFS_NO_SNAPSHOT change, and just clear the >> extra fs_snapinum[] entry ? > > > Without looking further I would suggest to print a warning, print the > fs_snapinum list and clear the entry as this inode is already an > active snapshot.
This will not work as we must remove the first duplicate which is already active. As this should only happen after a crash or unclean unmount this looks like a job for fsck. The attached diff teaches fsck_ffs to handle this inconsistency. Opinions? -- J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
001_fsck_snap
Description: Binary data
