I’m running LXD with zfs, but ever since i’ve installed them, every bootup i get an fsck. Is this standard behaviour with zfs on linux?
I’ve had zfs on solaris before, and there was an occasion the zpool wouldn’t export. On linux i experienced this the other day. There were no processes that were holding on to any file handles, since i had shut down all running containers. Using lsof and fuser, there’s was nothing hanging onto the the mount directory or the loop device i was using to present a block device for zfs. I remember this bit in the documents to keep 20% space free, and that’s the only thing i can think of that could have be a cause. Is this the case here?
Ah, so that may be the problem. Any reason you didn’t use the native file backend of zpool?
I suspect that ZFS won’t understand that it needs to undo the loop device when exporting the pool on shutdown, this will therefore keep your parent filesystem as busy, preventing it from going to read-only mode prior to shutdown and so having it be considered dirty at boot time.
It’s a case of seeing all problems as nails when holding a hammer. I’d clearly forgotten that vdevs can be physical files. One thing about doing this though, is that zfs related meta information etc should not even be seen by the underlying filesystem, since the zfs fs resides on a file, on another filesystem. I’d also tried unmounting zfs related real block devices before rebooting and it’s still the same ( i should retry that just to be sure ) . I mean writes on zfs and a sudden shutdown shouldn’t mean a dirty extfs, should it?
When your zpool is a file on an underlying filesystem, having ongoing writes to that during an unclean shutdown will make the underlying filesystem dirty.
On clean shutdown, you’d normally expect ZFS to get properly exported, eliminating that writer at the parent filesystem level, which then allows it to go read-only prior to shutdown/reboot and so booting back up clean. The use of a loop device here which isn’t getting undone is the issue as it keeps a write fd on the parent filesystem preventing it from cleanly going read-only and so booting back up dirty.
I’ve tried vdevs in another system with zfs, and the ext4 still requires fsck on boot. There’s 2 types of zfs in the ubuntu repository, one which spawns zfs_writes, trims,etc as part of kernel threads, and another is a fuse based zfs. I’m not using the fuse based ones, maybe that’s why.
