Date: Tue, 28 Feb 2017 20:54:25 +0100 From: Harry Schmalzbauer <freebsd@omnilan.de> To: ambrisko@freebsd.org Cc: freebsd-hackers@freebsd.org Subject: Re: Fix MNAMELEN or reimplement struct statfs Message-ID: <58B5D571.2010103@omnilan.de> In-Reply-To: <20150710154654.GA71708@ambrisko.com> References: <20140415233133.GA14686@ambrisko.com> <5452600C.5030003@omnilan.de> <20141101154004.GA40398@ambrisko.com> <559FD426.3000108@omnilan.de> <20150710154654.GA71708@ambrisko.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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? Greetings, -harry
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?58B5D571.2010103>