Date: Sun, 25 Oct 2015 11:11:11 +0000 From: Matthew Seaman <matthew@FreeBSD.org> To: freebsd-questions@freebsd.org Subject: Re: cd /.zfs/snapshot hangs (tmux put to uninterruptible sleep) Message-ID: <562CB8CF.7010504@FreeBSD.org> In-Reply-To: <562CB2C2.6090402@kulturflatrate.net> References: <562CB2C2.6090402@kulturflatrate.net>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --o5QeGTMkaKSdCJweirv41Ii1CgQesCXGM Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 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= =2E > Maybe it does now. >=20 > $ zfs list -t snapshot | wc -l > 1316 >=20 > 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.) >=20 > Nonetheless, there are not that much snapshots on the tank/root dataset= > that is mounted to /. >=20 > $ zfs list -t snapshot | grep tank/root | wc -l > 174 >=20 > So a `cd /.zfs/snapshot` should only list 174. >=20 > 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 no= w > freezed. >=20 >> $ 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 >=20 > `kill -9 21018` doesn't kill the process. I cannot return to tmux with > `tmux a` either. >=20 > 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 --o5QeGTMkaKSdCJweirv41Ii1CgQesCXGM Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQJ8BAEBCgBmBQJWLLjWXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2NTNBNjhCOTEzQTRFNkNGM0UxRTEzMjZC QjIzQUY1MThFMUE0MDEzAAoJELsjr1GOGkAT5aoQAJP5Niav0IFejNyDt+oGdXqR h5yfBC9/hEjww/eqrDlpAloZtNLYsZCJp4X/sYb8hXidvzkkYuMOpnYCG8ia93Za Bf6fkl8GjFkl3wfYf+EnU05BHZWK5ZHkPJVPEoHU7YmMJBs70YMtWkw3CjzyRYZZ BNI2ixjVet8Ir+ZdMfgWEIAxRVaubSEdPChTWs3MVPvnkqQVzXxqXrsGW/jC6waf NeBIMwgopmWxZXqt01wxVxbL/Pb5IN8dU5OBwqSuVV8E1Trqo2TsoVDnsphd2RVf +oWuIvUg7V/xrixXPqlj7Z4NWKYZlNlxzLjsVcd1MiKS4ssIO5Z2mGA2ZQF/B44/ gtJ9AO2UV8QtQ2c7cNXboHrhXQ6YxsUw5MCFBdKmX2UGMEUSdUsheVHhiAi4JtRP 5KBEaa1E6a18oL5ces8IaRWpdrzEIeuEAkmLMiCIK6MIcScqTFIXABgm3gfyXqjZ zS8Y/Acuj39jUgR/5X1rDxS6IxJXdBCpswg/hJtISH+yUMduVGgZtM/rx6zcngeW BDrvFffNbzSDkVfKgGRzI+cZXSYEB9Xvx92ira7FtPjTeYm0Q3H5GwIJ3znYj7/B eMRe+htHlRrJqBqn8GDRNsWMy/paj3p+T9AgrGbS3GbnnKUX5dRuU/7y1pOdYvzo 4eIDoUwNxth6NIqqngnN =GRJU -----END PGP SIGNATURE----- --o5QeGTMkaKSdCJweirv41Ii1CgQesCXGM--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?562CB8CF.7010504>