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