On Tue, Oct 02, 2018 at 12:11:49PM +0200, J. Hannken-Illjes wrote:
>
> > 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.
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 <bou...@antioche.eu.org>
NetBSD: 26 ans d'experience feront toujours la difference
--
