tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: panic: ffs_snapshot_mount: already on list



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

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 - hannken%eis.cs.tu-bs.de@localhost - TU Braunschweig (Germany)

Attachment: 001_fsck_snap
Description: Binary data



Home | Main Index | Thread Index | Old Index