Date: Fri, 10 Jul 2015 16:18:14 +0200 From: Harald Schmalzbauer <h.schmalzbauer@omnilan.de> To: Doug Ambrisko <ambrisko@ambrisko.com> Cc: freebsd-hackers@freebsd.org Subject: Re: Fix MNAMELEN or reimplement struct statfs Message-ID: <559FD426.3000108@omnilan.de> In-Reply-To: <20141101154004.GA40398@ambrisko.com> References: <20140415233133.GA14686@ambrisko.com> <5452600C.5030003@omnilan.de> <20141101154004.GA40398@ambrisko.com>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig059C4B624A70748D42259D0F Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable > | Hello, > |=20 > | first sorry for the missing thread references in the header, I'm not > | subscribed to hackers@. > |=20 > | bdrewery@ pointed me to this discussion in response to my question to= > | stable@ > | (http://lists.freebsd.org/pipermail/freebsd-fs/2014-August/019949.htm= l) > |=20 > | Last promising post I found: > |=20 > | > |/ > I have a new patch at: > | > /|/ > http://people.freebsd.org/~ambrisko/mount_bigger_2.patch <ht= tp://people.freebsd.org/%7Eambrisko/mount_bigger_2.patch> > | > /|/ > that I tested against head. This should be pretty close to c= ommiting > | > /|/ > unless people find some issues with it. > | > /|/=20 > | > /|/ In sys/kern/vfs_mount.c: > | > /|/ + mp->mnt_path =3D malloc(strlen(fspath), M_MOUNT, M_WAITOK); > | > /|/ + strlcpy((char *)mp->mnt_path, fspath, strlen(fspath)); > | > /|/=20 > | > /|/ This always strips the last byte off the fspath. > | > /|/=20 > | > /|/ I like that this only touches the kernel, so it does not break = anything > | > /|/ regarding mount/umount of filesystems with short paths, includi= ng > | > /|/ (NFS) filesystems that do not respond. > | > /|/=20 > | > /|/ The patch does not enlarge f_mntfromname which may be a problem= for > | > /|/ nullfs. It is certainly a step forwards for poudriere but [ENAM= ETOOLONG] > | > /|/ 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 use= s > | > 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 as= sume > | > that mount root would be short. > |=20 > | 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 o= n > | my rather lightly loaded local 10.1 storage box ??? almost all snapsh= ots > | 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=FCglich 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.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 :-) Since releng/10.2 is to be created soon, I'm testing RELENG_10 on some of my production machines, Therefore I cosmetically altered your patchset to make it work with -stable: ftp://ftp.omnilan.de/pub/FreeBSD/OmniLAN/misc/local-patches/RELENG_10/mou= nt_bigger_2_1.patch Have you made any progress in this area, e.g. is there anything different I can test, which might help in any way? Thanks, -Harry --------------enig059C4B624A70748D42259D0F Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAlWf1C4ACgkQLDqVQ9VXb8iIwACgny7GbWjZMQi2v/5dd2lg66Bt ZWcAoIgZaQhGJhacniSWYYBkxI6+ok0u =ZFbh -----END PGP SIGNATURE----- --------------enig059C4B624A70748D42259D0F--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?559FD426.3000108>