Attachment 205830 Details for Bug 237517 – Repro script (run from /)

Repro script (run from /)

zfs_wrong_order.sh (text/plain), 1.41 KB, created by fullermd on 2019-07-17 03:38:44 UTC

(hide)

Description:

Filename:

MIME Type:

Creator: fullermd

Created: 2019-07-17 03:38:44 UTC

Size: 1.41 KB

patch

obsolete

>#!/bin/sh
>
># A scratch pool
>BASE="ztst/t2fs"
>
># Make sure everything's unmounted
>zfs unmount -a
>
>
># Destroy and recreate the tree.
>zfs destroy -r ${BASE}
>zfs create ${BASE}
>
># Make one dir we'll put everything under, and one fs rooted there.
>zfs create -o mountpoint=/${BASE}/somedir ${BASE}/somefs
>zfs create ${BASE}/somefs/subdir
>
># And a differently named FS, rooted in the same place, but not
># mounting it.  Then make a FS under it (which _does_ get mounted).
>zfs create -o mountpoint=/${BASE}/somedir -o canmount=off ${BASE}/otherfs
>zfs create ${BASE}/otherfs/anotherdir
>
># Touch files
>for i in / somedir somedir/subdir somedir/anotherdir ; do
>	touch ${BASE}/${i}/afile
>done
>
>
>
># All visible right now
>echo "Created:"
>find /${BASE} -name 'afile' -print | sort
>
>
># Redo all the zfs mounts, in the default parallel.
># Some fraction of the time, the somedir and anotherdir contents are
># missing!  This appears to be something about how ZFS laid stuff out on
># disk, because when it happens, un/re-mounting will (almost?) always
># reproduce it, but when it doesn't, un-re'ing will (almost?) never.  So
># it's somewhat dependant on how the above creations got written out.
>zfs unmount -a
>zfs mount -a
>
>echo
>echo "Restarted:"
>find /${BASE} -name 'afile' -print | sort
>
>
># But mounted serially, they're always all there.
>zfs unmount -a
>env ZFS_SERIAL_MOUNT=1 zfs mount -a
>
>echo
>echo "Restarted serially:"
>find /${BASE} -name 'afile' -print | sort

Actions: View

Attachments on bug 237517: 204479 | 204484 | 204504 | 204524 | 204525 | 204788 | 205830 | 205857