cd /.zfs/snapshot hangs (tmux put to uninterruptible sleep)
Matthew Seaman
m.seaman at infracaninophile.co.uk
Mon Oct 26 11:44:33 UTC 2015
On 10/26/15 11:26, Matthew Seaman wrote:
> On 10/25/15 12:21, Niklaas Baudet von Gersdorff wrote:
>> On 25/10/15 13:14, Matthew Seaman wrote:
>>> Please do go ahead and reset your system. Just realizing it's happening
>>> to other people than me is sufficient incentive.
>>
>> OK. Thanks a lot for your help!
>>
>>> PS. If you need to access one of the troublesome snapshots, use 'zfs
>>> clone' -- it seems to avoid the various pitfalls.
>>
>> OK. Great.
>>
>
> Hmmm... I can't reproduce the problematic effect. I set up a zfs with
> snapshots like so:
>
> # zfs list -t all -r tank/.......1
> NAME
> USED AVAIL REFER MOUNTPOINT
> tank/.......1
> 19K 769G 19K /.......1
> tank/.......1 at ....3.........4.........5.........6.........7.........8........
> 0 - 19K -
> tank/.......1 at ....3.........4.........5.........6.........7.........8.........
> 0 - 19K -
> tank/.......1 at ....3.........4.........5.........6.........7.........8.........9.........0
> 0 - 19K -
>
> where the contents of the ZFS were:
>
> # find /.......1
> /.......1
> /.......1/aaa
> /.......1/aaa/bbb
> /.......1/aaa/bbb/ccc
>
> Sorry about the funky filenames -- they're just for counting the
> characters in the automount path for the snapshot. The result is like
> so (if you can make it out despite the line wrapping my mail client
> wants to add):
>
> # find /.......1/.zfs/snapshot
> /.......1/.zfs/snapshot
> find:
> /.......1/.zfs/snapshot/....3.........4.........5.........6.........7.........8.........:
> File name too long
> /.......1/.zfs/snapshot/....3.........4.........5.........6.........7.........8........
> /.......1/.zfs/snapshot/....3.........4.........5.........6.........7.........8......../aaa
> /.......1/.zfs/snapshot/....3.........4.........5.........6.........7.........8......../aaa/bbb
> /.......1/.zfs/snapshot/....3.........4.........5.........6.........7.........8......../aaa/bbb/ccc
> find:
> /.......1/.zfs/snapshot/....3.........4.........5.........6.........7.........8.........9.........0:
> File name too long
>
> # cd
> /.......1/.zfs/snapshot/....3.........4.........5.........6.........7.........8.........9.........0/aaa/bbb
>
> /.......1/.zfs/snapshot/....3.........4.........5.........6.........7.........8.........9.........0/aaa/bbb:
> File name too long.
>
>
> ie. a mounted path length of 88 characters is OK, but 89 or 100
> characters gets the 'name too long' error. However, I can't detect any
> problems after that. No processes stuck trying to do IO. So I guess
> that whatever the problem was, it has been fixed in 10.2-RELEASE
>
> Cheers,
>
> Matthew
>
>
Actually, here is the problem:
stingray:/:# zfs destroy -r tank/.......1
cannot unmount '/.......1': Device busy
But that is easily fixed by:
stingray:/:# zfs umount -f /.......1
stingray:/:# zfs destroy -r tank/.......1
I wonder if that's worth a PR? I recall now this is exactly what I ran
into before, but it seems rather different to what you're seeing.
Cheers,
Matthew
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-questions/attachments/20151026/6581d587/attachment.bin>
More information about the freebsd-questions
mailing list