Re: panic: ffs_snapshot_mount: already on list

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

On Tue, Oct 02, 2018 at 12:11:49PM +0200, J. Hannken-Illjes wrote:
> 
> > On 18. Sep 2018, at 16:39, J. Hannken-Illjes <hannken%eis.cs.tu-bs.de@localhost> wrote:
> > 
> > 
> >> On 18. Sep 2018, at 16:33, Manuel Bouyer <bouyer%antioche.eu.org@localhost> 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.

So maybe we could just print a warning and ignore the duplicates at mount
time ? Are shapshots checked on a read-only mount ?

> 
> 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.

I agree that fsck should also be able to cleanup this.

-- 
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
     NetBSD: 26 ans d'experience feront toujours la difference
--