From owner-freebsd-stable@freebsd.org Thu Sep 29 14:32:21 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8C9AFC01135 for ; Thu, 29 Sep 2016 14:32:21 +0000 (UTC) (envelope-from dweimer@dweimer.net) Received: from webmail.dweimer.net (24-240-198-188.static.stls.mo.charter.com [24.240.198.188]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 53EFEDF3 for ; Thu, 29 Sep 2016 14:32:20 +0000 (UTC) (envelope-from dweimer@dweimer.net) Received: from webmail.dweimer.local (localhost [10.9.5.2]) by webmail.dweimer.net (8.15.2/8.15.2) with ESMTPS id u8TEWCF7097115 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 29 Sep 2016 09:32:12 -0500 (CDT) (envelope-from dweimer@dweimer.net) Received: (from www@localhost) by webmail.dweimer.local (8.15.2/8.15.2/Submit) id u8TEWBjs097114; Thu, 29 Sep 2016 09:32:11 -0500 (CDT) (envelope-from dweimer@dweimer.net) X-Authentication-Warning: webmail.dweimer.local: www set sender to dweimer@dweimer.net using -f To: FreeBSD Stable Subject: File Name Too Long? MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 29 Sep 2016 09:32:11 -0500 From: "Dean E. Weimer" Organization: dweimer.net Reply-To: dweimer@dweimer.net Mail-Reply-To: dweimer@dweimer.net Message-ID: <974bc572bedda786fdc18a41085952c1@dweimer.net> X-Sender: dweimer@dweimer.net User-Agent: Roundcube Webmail/1.2.1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2016 14:32:21 -0000 I discovered, unfortunately by deleting a jail by accident, that my backup process isn't working. At least it was only the operating system part of the jail, I still have all the data so I just need to reinstall the operating system. While the ports are in the process of building I started to investigate the cause, because the backup logs report everything was fine. I have a custom pre-backup script I wrote that takes snapshots of my ZFS datasets, and then mounts those under /mnt/backup with nullfs mount points to the .zfs/snapshot/.. directories then I back them up rather than the live file system, allowing me to stop some services that don't restore from a running state correctly and then restart after the snapshot so downtime is only a couple of minutes instead of full length of backups. It appeared to be running perfectly, without errors, but apparently the script isn't reporting some nullfs mount failures, so why are the failing, turns out it thinks the file name is too long? but looking at the mount(2) man page it states this: [ENAMETOOLONG] A component of a pathname exceeded 255 characters, or the entire length of a path name exceeded 1023 characters. I can see that at some point under this, I may reach that 1023 limit, but what of the total 71 characters in this path has a problem? /jails/unifi/ROOT/.zfs/snapshot/11.0-RELEASE-r306379-2016.09.28--bsnap root@freebsd:/jails/unifi/ROOT/.zfs/snapshot # ls ls: 11.0-RELEASE-r306379-2016.09.28--bsnap: File name too long I thought, maybe its a ZFS specific error, and ran across this: http://lists.freebsd.org/pipermail/freebsd-fs/2010-March/007964.html [..snip..] From looking at the code, I think you hitting this limit: /* * Be ultra-paranoid about making sure the type and fspath * variables will fit in our mp buffers, including the * terminating NUL. */ if (strlen(fstype) >= MFSNAMELEN || strlen(fspath) >= MNAMELEN) return (ENAMETOOLONG); in vfs_domount() or vfs_donmount(). This is FreeBSD limit caused by statfs structure: /* * filesystem statistics */ [...] #define MNAMELEN 88 /* size of on/from name bufs */ [...] struct statfs { [...] char f_mntfromname[MNAMELEN];/* mounted filesystem */ char f_mntonname[MNAMELEN]; /* directory on which mounted */ }; When you list .zfs/snapshot/ directory (especially with -l option) ZFS mounts snapshots on lookup and this is this mount that fails. [..snip..] I can seemingly due anything else with the snapshot, clone, send, receive its just that I am unable to access the files on it through .zfs/snapshot/.. I am trying to find what the limit is here from this, because this one here works. /jails/webmail/usr-local-subversion/.zfs/snapshot/usr-local-subversion--bsnap its longer in total length than most of the ones that are failing. /jails/unifi/ROOT/.zfs/snapshot/11.0-RELEASE-r306379-2016.09.28--bsnap So it appears that its in the name, and not the mount point. this one works as well, which is my ZFS boot environment on the main system zraid/ROOT/11.0-RELEASE-r306379-2016.09.28 snapshot is /.zfs/snapshot/11.0-RELEASE-r306379-2016.09.28--bsnap So its not just the last component of the zfs dataset name, which is in this case the same. I am trying to wrap my head around this and find where the limit is so I can adjust my naming conventions used and actually get backups of all of my data. Turns out all of my jail operating system paths aren't being backed up, fortunately at least all of the data file systems for the jails are. -- Thanks, Dean E. Weimer http://www.dweimer.net/