Date: Tue, 28 Feb 2017 12:17:54 -0800 From: Doug Ambrisko <ambrisko@ambrisko.com> To: Harry Schmalzbauer <freebsd@omnilan.de> Cc: ambrisko@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: Fix MNAMELEN or reimplement struct statfs Message-ID: <20170228201753.GA99322@ambrisko.com> In-Reply-To: <58B5D571.2010103@omnilan.de> References: <20140415233133.GA14686@ambrisko.com> <5452600C.5030003@omnilan.de> <20141101154004.GA40398@ambrisko.com> <559FD426.3000108@omnilan.de> <20150710154654.GA71708@ambrisko.com> <58B5D571.2010103@omnilan.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Feb 28, 2017 at 08:54:25PM +0100, Harry Schmalzbauer wrote: | Bezüglich Doug Ambrisko's Nachricht vom 10.07.2015 17:46 (localtime): | > On Fri, Jul 10, 2015 at 04:18:14PM +0200, Harald Schmalzbauer wrote: | > | | > | > | Hello, | > | > | | > | > | first sorry for the missing thread references in the header, I'm not | > | > | subscribed to hackers@. | > | > | | > | > | bdrewery@ pointed me to this discussion in response to my question to | > | > | stable@ | > | > | (http://lists.freebsd.org/pipermail/freebsd-fs/2014-August/019949.html) | > | > | | > | > | Last promising post I found: | > | > | | > | > | > |/ > I have a new patch at: | > | > | > /|/ > http://people.freebsd.org/~ambrisko/mount_bigger_2.patch <http://people.freebsd.org/%7Eambrisko/mount_bigger_2.patch>; | > | > | > /|/ > that I tested against head. This should be pretty close to commiting | > | > | > /|/ > unless people find some issues with it. | > | > | > /|/ | > | > | > /|/ In sys/kern/vfs_mount.c: | > | > | > /|/ + mp->mnt_path = malloc(strlen(fspath), M_MOUNT, M_WAITOK); | > | > | > /|/ + strlcpy((char *)mp->mnt_path, fspath, strlen(fspath)); | > | > | > /|/ | > | > | > /|/ This always strips the last byte off the fspath. | > | > | > /|/ | > | > | > /|/ I like that this only touches the kernel, so it does not break anything | > | > | > /|/ regarding mount/umount of filesystems with short paths, including | > | > | > /|/ (NFS) filesystems that do not respond. | > | > | > /|/ | > | > | > /|/ The patch does not enlarge f_mntfromname which may be a problem for | > | > | > /|/ nullfs. It is certainly a step forwards for poudriere but [ENAMETOOLONG] | > | > | > /|/ errors could still occur in more extreme situations. | > | > | > / | > | > | > Good point on nullfs. I'll look at fixing that. To do that I'm | > | > | > changing mnt_path to mnt_topath so then I can have a mnt_frompath. | > | > | > I'll add nullfs to my test cases. I'll need to run through the uses | > | > | > of f_mntfromname. It was pretty easy with f_mntonname since it was | > | > | > only allocated in one place just used a bunch of other place. I assume | > | > | > that mount root would be short. | > | > | | > | > | Thanks a lot so far for working hard on that problem! | > | > | Is there anything newer than "mount_bigger_2.patch", which considers | > | > | potential nullfs problems? | > | > | I'm heavily using nullfs (without poudriere), but I'd give it a try on | > | > | my rather lightly loaded local 10.1 storage box ??? almost all snapshots | > | > | are useless, can't access them in case of the case; which happens | > | > | frequently :-( | > | > | Would I have to expect any nullfs regressions with the april | > | > | (mount_bigger_2) patch?? | > | | > | Bez?glich Doug Ambrisko's Nachricht vom 01.11.2014 16:40 (localtime): | > | > I should be able to resume working on this since things are starting to | > | > slow down. It shouldn't be much more work to get it finished off to | > | > put up for review. | > | | > | Hello Doug, | > | | > | I've been using your mount_bigger_2.patch for some months without | > | problems, but haven't done any kind of stress test. | > | It just saves my soul in case I have to recover files from | > | (zfs-)snapshots from time to time :-) | > | | | Hello Doug, | | I hope you are fine! | Nice website, which I checked to see if you gave up on FreeBSD, before | trying to nag you ;-) | | <HTML> | <HEAD> | <TITLE>Welcome Page</TITLE> | <META NAME="GENERATOR" CONTENT="Mozilla/3.01Gold (X11; I; FreeBSD 2.2-CURRENT i386) [Netscape]"> | | :-) :-) :-) | | But I saw r307326, so I thought it's time for my annual | "mount_bigger_2_1.patch" status question ;-) | | | I'm currently planning to upgrade some machines from 10 to 11-stable, | where I've been happyly running your patch. | Any updates on the MNAMELEN front? I nearby read about plans to extend | it to ?1000:1088?. | | But just for now I'd highly appreciate if you could tell me if you are | ware of any objections applying your | mount_bigger_2.patch on 11-stable. | | Hope you don't mind if I quote a question from about a year ago: | | Bezüglich Harry Schmalzbauer's Nachricht vom 19.11.2015 11:38 (localtime): | … | >> | I've been using your mount_bigger_2.path for some months without | >> | problems, but haven't done any kind of stress test. | >> | It just saves my soul in case I have to recover files from | >> | (zfs-)snapshots from time to time :-) | > | > Hello Doug, | > | > unfortunately, mount_bigger doesn't cover the length restriction for | > make_dev_p(), which leads to inaccessable zvols | > (g_dev_taste: make_dev_p() failed | > (gp->name=zvol/babasP0.1xSATA7k2-0/liveBACKSTOR/zfsREPL/esm-vega/P1/iscsi.redtsdatahdd500@epochp2, | > error=63)) | | Do you have anything handy which solves the make_dev_p() limitation? This got lost in my emails. I need to clean out my home emails. Too many things get lost on I need to go back and look at it but then forget what. I was going to look at the this issue when I got a free moment but then couldn't find it. Do you have a simple repro. to show this. It would be great if the repo. was based on md disk that was ZFS created, mounted and this done to. Then I can repro. it locally and look at it. I have bhyve setup to UEFI PXE boot on my laptop to test things out. I'm still waiting for 64 bit inodes to come in which is supposed to help with this and make it not needed. I'm still running this code and need to put it on my laptop since I've run into this issue there now. It's been nice that people haven't been changing things so the patch still applies. Although it touches a bunch of files it doesn't touch much. I wanted it to be fairly transparent. The main piece missing is getting the full paths back to user-land so that running mount would show them versus the trancated versus. I had some ideas on that but stopped looking at it. A hack could be done to use a sysctl to pass that info. like some other tools use. Thanks, Doug A.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20170228201753.GA99322>