Re: svn commit: r344316 - head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs
On Feb 20, 2019, at 09:11, Rodney W. Grimes wrote: > One can personally link ZoL into your own kernel, and a company/corporate > can even do this and run it on 1000's of servers, you just can not > distribute it to anyone else, which in the end is not really a big > deal, unless your in the Linux distribution business. Very little organizations roll their own Linux kernels in the grand scheme of things (run of the mill sysadmins aren’t hackers), and making Linux VFS work with ZFS is a nontrivial job (ZoL might work with a kernel version, but it won’t work with all target kernel versions). Groups like Facebook, Google, Oracle, etc, do it because they have the developer manpower and it’s in their vested interest to run a custom kernel config/kernel with backports/enhancements. Plus, they don’t need to release their changes, as their server platforms won’t be productized (thus skating around the GPLv2). I couldn’t find gregkh@‘s diatribe about Linux kernel compatibility, but it was basically (put nicely), “put your code in the kernel tree, cause we won’t necessarily provide backwards compatibility, as we need to break interfaces from time to time.” Given that zfs is licensed under the CDDL (a viral license to Linux), that code will never, ever, hit the mainline tree. This is one of the code reasons why, over time, btrfs has evolved into the file system that it is: it fills a niche that ext4 couldn’t and zfs did, while being licensed under an acceptable kernel license (GPLv2). -Enji ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r344316 - head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs
On February 20, 2019 9:01:53 AM PST, Enji Cooper wrote: > >> On Feb 19, 2019, at 23:56, Alexey Dokuchaev >wrote: >> >>> On Tue, Feb 19, 2019 at 06:43:28PM -0500, Shawn Webb wrote: >>> At the risk of painting a bikeshed a lovely color of neon purple, >I'm >>> curious about if/how these types of commits get merged upstream to >>> (OpenZFS|Illumos|ZFS On Linux|where ever ZFS upstream is now|I'm >very >>> confused|is anyone else confused where upstream is?). >>> >>> Who is upstream? Is work like this going to remain as a downstream >>> patch to ZFS? Or is FreeBSD going to work to upstream this type of >>> work? >> >> I've always felt that we should've become upstream to everyone else >> the moment we knew Oracle would eat Sun (20 April 2009), and never >> understood why it didn't happen and now, ten years later, we're >talking >> about ZFS on fucking Linux becoming our upstream. Something'd got >very >> wrong here and I'd like to know what and why. > >As others have pointed out, FreeBSD has less developer inertia than >Linux, and there are (seemingly) less developers or interested parties >in running an openindiana based stack. > >Also: better OS support for other general purpose >infrastructure/usecases with items like multitenancy via >containerization/CGroups2, Java, etc, and mindshare around this and >other things. > >The only thing really holding ZoL back in Linux is the fact that (due >to licensing) it won’t ever be in the Linux kernel. > >-Enji Exactly. This and the fact that our user base is considerably smaller, we don't have the gravitas and must settle being dictated to. POSIX is dead. I suppose a person could get on top of the soapbox again but ... A way forward might be two pronged. Yes, maintain ZoF based on ZoL, illumos, or both, and a Linux KPI layer to allow ZoL (and anything else for that matter) to be imported into ports. However maintaining a great shim to the exclusion of good native support is existential. -- Pardon the typos and autocorrect, small keyboard in use. Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r344316 - head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs
> > On Feb 19, 2019, at 23:56, Alexey Dokuchaev wrote: > > > >> On Tue, Feb 19, 2019 at 06:43:28PM -0500, Shawn Webb wrote: > >> At the risk of painting a bikeshed a lovely color of neon purple, I'm > >> curious about if/how these types of commits get merged upstream to > >> (OpenZFS|Illumos|ZFS On Linux|where ever ZFS upstream is now|I'm very > >> confused|is anyone else confused where upstream is?). > >> > >> Who is upstream? Is work like this going to remain as a downstream > >> patch to ZFS? Or is FreeBSD going to work to upstream this type of > >> work? > > > > I've always felt that we should've become upstream to everyone else > > the moment we knew Oracle would eat Sun (20 April 2009), and never > > understood why it didn't happen and now, ten years later, we're talking > > about ZFS on fucking Linux becoming our upstream. Something'd got very > > wrong here and I'd like to know what and why. > > As others have pointed out, FreeBSD has less developer inertia than Linux, > and there are (seemingly) less developers or interested parties in running > an openindiana based stack. > > Also: better OS support for other general purpose infrastructure/usecases > with items like multitenancy via containerization/CGroups2, Java, etc, > and mindshare around this and other things. > > The only thing really holding ZoL back in Linux is the fact that (due > to licensing) it won?t ever be in the Linux kernel. One can personally link ZoL into your own kernel, and a company/corporate can even do this and run it on 1000's of servers, you just can not distribute it to anyone else, which in the end is not really a big deal, unless your in the Linux distribution business. -- Rod Grimes rgri...@freebsd.org ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r344316 - head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs
> On Feb 19, 2019, at 23:56, Alexey Dokuchaev wrote: > >> On Tue, Feb 19, 2019 at 06:43:28PM -0500, Shawn Webb wrote: >> At the risk of painting a bikeshed a lovely color of neon purple, I'm >> curious about if/how these types of commits get merged upstream to >> (OpenZFS|Illumos|ZFS On Linux|where ever ZFS upstream is now|I'm very >> confused|is anyone else confused where upstream is?). >> >> Who is upstream? Is work like this going to remain as a downstream >> patch to ZFS? Or is FreeBSD going to work to upstream this type of >> work? > > I've always felt that we should've become upstream to everyone else > the moment we knew Oracle would eat Sun (20 April 2009), and never > understood why it didn't happen and now, ten years later, we're talking > about ZFS on fucking Linux becoming our upstream. Something'd got very > wrong here and I'd like to know what and why. As others have pointed out, FreeBSD has less developer inertia than Linux, and there are (seemingly) less developers or interested parties in running an openindiana based stack. Also: better OS support for other general purpose infrastructure/usecases with items like multitenancy via containerization/CGroups2, Java, etc, and mindshare around this and other things. The only thing really holding ZoL back in Linux is the fact that (due to licensing) it won’t ever be in the Linux kernel. -Enji ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r344316 - head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs
> On Tue, Feb 19, 2019 at 06:43:28PM -0500, Shawn Webb wrote: > > At the risk of painting a bikeshed a lovely color of neon purple, I'm > > curious about if/how these types of commits get merged upstream to > > (OpenZFS|Illumos|ZFS On Linux|where ever ZFS upstream is now|I'm very > > confused|is anyone else confused where upstream is?). > > > > Who is upstream? Is work like this going to remain as a downstream > > patch to ZFS? Or is FreeBSD going to work to upstream this type of > > work? > > I've always felt that we should've become upstream to everyone else > the moment we knew Oracle would eat Sun (20 April 2009), and never > understood why it didn't happen and now, ten years later, we're talking > about ZFS on fucking Linux becoming our upstream. Something'd got very > wrong here and I'd like to know what and why. I think to answer why ZoL wins out over ZoF in the upstream selection is that ZoL has many more people working on it than does ZoF so they innovate much faster than us, that makes them a good choose in the since that developement moves faster. I do, like many, have reservations about other aspects perhaps not making this an ideal, but if ZoL develope a good developement model, they well kick ass over anything the FreeBSD project could ever do with ZFS. Like it or not, they have a larger critical mass than us, and that wins in the end game. Also since we did choose to be downstream from illumous that put is in the follow mode in many aspects, so we did not grow a bunch of ZFS developers, where as the ZoL project kinda grabbed the code and went full tilt with it, not totally ignoring upstream, but also not letting upstream stifle there efforts. > > > I hope my curiousity doesn't offend anyone. ;) > Not at all, I'm also confused and curious. Now running a ZoL instance just so I can get use to its look and feel and see how if at all it plays along with ZoF. > ./danfe -- Rod Grimes rgri...@freebsd.org ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r344316 - head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs
> On 20 Feb 2019, at 09:56, Alexey Dokuchaev wrote: > > On Tue, Feb 19, 2019 at 06:43:28PM -0500, Shawn Webb wrote: >> At the risk of painting a bikeshed a lovely color of neon purple, I'm >> curious about if/how these types of commits get merged upstream to >> (OpenZFS|Illumos|ZFS On Linux|where ever ZFS upstream is now|I'm very >> confused|is anyone else confused where upstream is?). >> >> Who is upstream? Is work like this going to remain as a downstream >> patch to ZFS? Or is FreeBSD going to work to upstream this type of >> work? > > I've always felt that we should've become upstream to everyone else > the moment we knew Oracle would eat Sun (20 April 2009), and never > understood why it didn't happen and now, ten years later, we're talking > about ZFS on fucking Linux becoming our upstream. Something'd got very > wrong here and I'd like to know what and why. > >> I hope my curiousity doesn't offend anyone. ;) > > Not at all, I'm also confused and curious. > > ./danfe > The genuine lack of developers and development. If the updates do happen in ZoL (for zfs), it only means the developers find it easier to work there. rgds, toomas ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r344316 - head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs
On Tue, Feb 19, 2019 at 06:43:28PM -0500, Shawn Webb wrote: > At the risk of painting a bikeshed a lovely color of neon purple, I'm > curious about if/how these types of commits get merged upstream to > (OpenZFS|Illumos|ZFS On Linux|where ever ZFS upstream is now|I'm very > confused|is anyone else confused where upstream is?). > > Who is upstream? Is work like this going to remain as a downstream > patch to ZFS? Or is FreeBSD going to work to upstream this type of > work? I've always felt that we should've become upstream to everyone else the moment we knew Oracle would eat Sun (20 April 2009), and never understood why it didn't happen and now, ten years later, we're talking about ZFS on fucking Linux becoming our upstream. Something'd got very wrong here and I'd like to know what and why. > I hope my curiousity doesn't offend anyone. ;) Not at all, I'm also confused and curious. ./danfe ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r344316 - head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs
On Tue, Feb 19, 2019 at 11:35:56PM +, Pawel Jakub Dawidek wrote: > Author: pjd > Date: Tue Feb 19 23:35:55 2019 > New Revision: 344316 > URL: https://svnweb.freebsd.org/changeset/base/344316 > > Log: > The way ZFS searches for its vdevs is the following: first it looks for > a vdev that has the same name as the one stored in metadata and that has > all VDEV labels in place. If it cannot find a GEOM provider with the given > name and all VDEV labels it will scan all GEOM providers for the best match > (the most VDEV labels available), but here the name is ignored. > > In case the ZFS pool is created, eg. using GPT partition label: > > # zpool create tank /dev/gpt/tank > > everything works, and on every import ZFS will pick /dev/gpt/tank and > not /dev/da0p4. > > The problem occurs when da0p4 is extended and ZFS is unable to find all > VDEV labels in /dev/gpt/tank anymore (the VDEV labels stored at the end > of the partition are now somewhere else). In this case it will scan all > GEOM providers and will pick the first one with the best match, ie. da0p4. > > Fix this problem by checking the VDEV/provider name even if we get the same > match. If the name is the same as the one we have in pool's metadata, prefer > this GEOM provider. > > Reported by:oshogbo, Michal Mroz > Tested by: Michal Mroz > Obtained from: Fudo Security > > Modified: > head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_geom.c At the risk of painting a bikeshed a lovely color of neon purple, I'm curious about if/how these types of commits get merged upstream to (OpenZFS|Illumos|ZFS On Linux|where ever ZFS upstream is now|I'm very confused|is anyone else confused where upstream is?). Who is upstream? Is work like this going to remain as a downstream patch to ZFS? Or is FreeBSD going to work to upstream this type of work? I hope my curiousity doesn't offend anyone. ;) Thanks, -- Shawn Webb Cofounder and Security Engineer HardenedBSD Tor-ified Signal:+1 443-546-8752 Tor+XMPP+OTR:latt...@is.a.hacker.sx GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE signature.asc Description: PGP signature
svn commit: r344316 - head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs
Author: pjd
Date: Tue Feb 19 23:35:55 2019
New Revision: 344316
URL: https://svnweb.freebsd.org/changeset/base/344316
Log:
The way ZFS searches for its vdevs is the following: first it looks for
a vdev that has the same name as the one stored in metadata and that has
all VDEV labels in place. If it cannot find a GEOM provider with the given
name and all VDEV labels it will scan all GEOM providers for the best match
(the most VDEV labels available), but here the name is ignored.
In case the ZFS pool is created, eg. using GPT partition label:
# zpool create tank /dev/gpt/tank
everything works, and on every import ZFS will pick /dev/gpt/tank and
not /dev/da0p4.
The problem occurs when da0p4 is extended and ZFS is unable to find all
VDEV labels in /dev/gpt/tank anymore (the VDEV labels stored at the end
of the partition are now somewhere else). In this case it will scan all
GEOM providers and will pick the first one with the best match, ie. da0p4.
Fix this problem by checking the VDEV/provider name even if we get the same
match. If the name is the same as the one we have in pool's metadata, prefer
this GEOM provider.
Reported by: oshogbo, Michal Mroz
Tested by:Michal Mroz
Obtained from:Fudo Security
Modified:
head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_geom.c
Modified: head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_geom.c
==
--- head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_geom.c Tue Feb
19 23:24:39 2019(r344315)
+++ head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_geom.c Tue Feb
19 23:35:55 2019(r344316)
@@ -692,10 +692,12 @@ vdev_geom_attach_by_guids(vdev_t *vd)
struct g_geom *gp;
struct g_provider *pp, *best_pp;
struct g_consumer *cp;
+ const char *vdpath;
enum match match, best_match;
g_topology_assert();
+ vdpath = vd->vdev_path + sizeof("/dev/") - 1;
cp = NULL;
best_pp = NULL;
best_match = NO_MATCH;
@@ -710,6 +712,10 @@ vdev_geom_attach_by_guids(vdev_t *vd)
if (match > best_match) {
best_match = match;
best_pp = pp;
+ } else if (match == best_match) {
+ if (strcmp(pp->name, vdpath) == 0) {
+ best_pp = pp;
+ }
}
if (match == FULL_MATCH)
goto out;
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
