cd /.zfs/snapshot hangs (tmux put to uninterruptible sleep)

Matthew Seaman matthew at FreeBSD.org
Sun Oct 25 11:11:24 UTC 2015


On 25/10/2015 10:45, Niklaas Baudet von Gersdorff wrote:
> When I cd into /.zfs/.snapshot the shell hangs. I must confess, there
> are a lot of snapshots because I never thought this may cause a problem.
> Maybe it does now.
> 
> $ zfs list -t snapshot | wc -l
>     1316
> 
> These are hourly, daily, weekly backups. I keep them for some time but
> delete old ones. They accumulate because I have several jails with a
> independent datasets on the system. (In case someone wonders why there
> are that much.)
> 
> Nonetheless, there are not that much snapshots on the tank/root dataset
> that is mounted to /.
> 
> $ zfs list -t snapshot | grep tank/root | wc -l
>      174
> 
> So a `cd /.zfs/snapshot` should only list 174.
> 
> Why am I not able to see the output of `cd /.zfs/snapshot`? Did I reach
> the limit of possible snapshots?

I don't think it's the number of snapshots that's causing the problem,
but that you've tried to create a snapshot that breaks a limit on the
path length of a mount point.  See for instance:

https://lists.freebsd.org/pipermail/freebsd-fs/2010-March/007964.html

Even though that report is five years old, the same limits still apply
today.

When you run into the limit, it is not that the snapshot automount
simply fails: it leaves the system in a less than ideal state, and you
have to force unmount the path where the the snapshot would have been
mounted.

  umount -f /.zfs/snapshot/some-directory

> Related to this problem: I ran the command in a tmux session that is now
> freezed.
> 
>> $ ps -lJ 0 | grep 'tmux: server'
>>  1001 21018     1   0  20   0 42396 19432 zfs      Ds    -       0:55.71 tmux: server (/tmp/tmux-1001/default) (
>>  1001 86447 85718   0  20   0 18808  2236 piperd   S+   20       0:00.00 grep tmux: server
> 
> `kill -9 21018` doesn't kill the process. I cannot return to tmux with
> `tmux a` either.
> 
> Any help is very much appreciated.

Unfortunately when a process gets into state 'D' there doesn't seem to
be anything that can be done, short of rebooting the machine, to get rid
of it.  If anyone knows any different I'd be glad to hear of it.

	Cheers,

	Matthew



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 957 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-questions/attachments/20151025/7acb9876/attachment.bin>


More information about the freebsd-questions mailing list