From owner-freebsd-stable@freebsd.org Fri Sep 30 19:36:08 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 B0F87C0368A for ; Fri, 30 Sep 2016 19:36:08 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6F738A05 for ; Fri, 30 Sep 2016 19:36:08 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: by mail-yw0-x22a.google.com with SMTP id i129so75147385ywb.0 for ; Fri, 30 Sep 2016 12:36:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=longcount-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=N6W5kyNvnKyEVgGPVb1yUTpbd50o/DxlubiGvVMsEAE=; b=Hyzbv6WQGFkK2UDamC9trA/Ijew20zysGV49vuVSVoNHs2RtgFe7FeeaJFeLOy/vgf F+eIW0/nR1IRFgkw1GFh9/HEOew+ezffuhI9TFQeGv5++YicR3Y6kts156bn0LH9zaMC Q/Y3yTOQyvXS6GlT8e6i/asNISF3cD9Q+UTjfU+OV1D5Jrc4ReG0DcJq77bMtZgCN0un V20EArm7lR6DfYJ1GUrX80kFaNxIadfKCOvKMLBZMFznL1UhJYqZ+PTElMCZT8w90NXR OR1AIYZ7De7YrYdNPYd7WsHrnzMHPy241HIiquBCSo2HY7HFL3j2vas+a1Y9c7X2P7vc cjGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=N6W5kyNvnKyEVgGPVb1yUTpbd50o/DxlubiGvVMsEAE=; b=VAB6uQ7Fzwb6J7IZ+eronfOui56X/pLLXVWqxMipTfThEqxoUMJP6OAP6C2Nrhnksn BxFRL5ULHfi02Po45TWrbx318Tz3zGM4iAK9U6FJSUMDbipEIkDotc0eyReIGx+Fc0pb jw5xmDrihCtfh3cvXCAbPZoHBz7MgwJ7IwpbPTtbsFcaNjgJZgdNTeovikl8ZbNpPWeR cO2N3qLslV4MhGZz4Ltye0OcO9xOztDIt6gJxlqg0ZE/hKPehrO/Nd62Jg5GIN3T1MyB 5otAL9OpTyJC0hAERS85aKkPzPgO8+7psyo5XnCQqYxi+V8FZqafY+/w9lVkFEwiPLuu VJCw== X-Gm-Message-State: AA6/9RmE6rHUaVuJUUxb+KvU/Gv+wfTCVKLssvLJ3qVw2cmGuyaHrwo+NyV3VQ8gbntzxp+YPu/xeknEGzT2nQ== X-Received: by 10.13.198.194 with SMTP id i185mr5592640ywd.132.1475264167371; Fri, 30 Sep 2016 12:36:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.230.68 with HTTP; Fri, 30 Sep 2016 12:36:06 -0700 (PDT) X-Originating-IP: [24.44.110.108] In-Reply-To: <7cb903d1b035e6bc1d311c1c37f57fd7@dweimer.net> References: <974bc572bedda786fdc18a41085952c1@dweimer.net> <1475246346.1079471.741974313.29D6C2CB@webmail.messagingengine.com> <7cb903d1b035e6bc1d311c1c37f57fd7@dweimer.net> From: Mark Saad Date: Fri, 30 Sep 2016 15:36:06 -0400 Message-ID: Subject: Re: File Name Too Long? To: dweimer@dweimer.net Cc: Priyadarshan , owner-freebsd-stable@freebsd.org, FreeBSD Stable Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 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: Fri, 30 Sep 2016 19:36:08 -0000 On Fri, Sep 30, 2016 at 10:52 AM, Dean E. Weimer wrote: > On 2016-09-30 9:39 am, Priyadarshan wrote: > >> On Fri, 30 Sep 2016, at 14:34, Dean E. Weimer wrote: >> >>> On 2016-09-29 9:32 am, Dean E. Weimer wrote: >>> > 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. >>> >>> I found a solution, I was naming the snapshots with the dataset name, >>> which I think was causing the issue. >>> >>> The following didn't seem to long to be an issue >>> /jails/unifi/ROOT/.zfs/snapshot/11.0-RELEASE-r306379-2016.09.28--bsnap >>> >>> But apparently the snapshot name was >>> zraid/jails/unifi/11.0-RELEASE-r306379-2016.09.28@11.0- >>> RELEASE-r306379-2016.09.28--bsnap >>> >>> Still not sure how it adds up to too long, both full paths together >>> aren't over 255, at 160, but apparently something else is added in >>> there. I was able to easily modify my backup script to not include the >>> last part of the dataset in the snapshot name and simply use -bsnap-, as >>> the name. it appears to avoid all the issues, and my backups from last >>> night include all the files. >>> >>> /jails/unifi/ROOT/.zfs/snapshot/-bsnap- >>> zraid/jails/unifi/11.0-RELEASE-r306379-2016.09.28@-bsnap- >>> >>> The total path now only adds up to 98, I haven't done any testing yet to >>> find out where the limit is hit, The longest combination of these I had >>> last night would have added up to 135, and that worked >>> >>> -- >>> Thanks, >>> Dean E. Weimer >>> http://www.dweimer.net/ >>> >> >> >> This may be related: >> >> http://iocage.readthedocs.io/en/latest/known-issues.html#cha >> racter-mount-path-limitation >> >> Priyadarshan >> > > Having run into this before in nfs exports , and pulling my hair out; I ran into this fix . I know its from a long time ago; but I am willing to put up a bounty to get this bumped to 512 http://www.secnetix.de/olli/FreeBSD/mnamelen.hawk > Thanks, that's probably it, the original snapshot name with its full data > set path added up to 89, with that in mind I can edit my script to throw a > warning if this limit is hit so that my backup logs will let me know if a > data set gets missed. I need to edit it anyways so that a warning gets > logged on the mount failure which was already occurring. It looks like I > escaped the errors, so that the script returned successful and didn't make > the Bacula backup job fail so that the data that did get mounted would be > backed up, but forgot to write the error to the log. > > -- > Thanks, > Dean E. Weimer > http://www.dweimer.net/ > _______________________________________________ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > -- mark saad | nonesuch@longcount.org