As a side note. I'm quietly using the patchset and the stability has never been so good as with those patches. Over the years I have tried to use unionfs to mount /usr/ports and /usr/src over NFS while the objects files stayed local at the client side. I was never able to do a complete build, without a crash. With this patchset I haven't had a single crash, even on SMP systems. Lots of kudos for the work -----Original Message----- From: owner-freebsd-hackers_at_freebsd.org [mailto:owner-freebsd-hackers_at_freebsd.org] On Behalf Of Scott Long Sent: Thursday, March 16, 2006 1:36 PM To: Daichi GOTO Cc: Jan Mikkelsen; ozawa_at_ongs.co.jp; freebsd-hackers_at_freebsd.org; freebsd-fs_at_freebsd.org; freebsd-current_at_freebsd.org; 'Mars G. Miro' Subject: Re: patchset-9 release (Re: [unionfs][patch] improvements of the unionfs - Problem Report, kern/91010) Daichi GOTO wrote: > Jan Mikkelsen wrote: > >> Daichi GOTO wrote: >> >>> All folks have interests in improved unionfs should keep attentions >>> and ask "how about merge?" at every turn :) >> >> >> OK. How about a merge? >> >> I'd really like to see this in 6-STABLE. > > > Me too, but unfortunately it is difficult with some reasons > (detail information http://people.freebsd.org/~daichi/unionfs/). > Of course, our patch gives the conditions for integration of > -current OK. For -stable is BAD. > > We must keep the API compatibility of command/library > for integration of -stable. With some technical/specifical > reasons, our improved unionfs has a little uncompatibility. > > For the last time, integration of -stable will be left > to the judgment of src committers and others. > >> Regards, >> >> Jan Mikkelsen. > > Right now, unionfs is somewhat usable for read-only purposes. As long as your work doesn't alter or break the behaviour of read-only mounts, I think it's very much ready to go into CVS. From there it can get wider testing and review and be considered for 6-stable. Since read-write support in the existing code is pretty much worthless, I don't think that there will be a problem justifying the operational changes that you describe in your documentation. Scott _______________________________________________ freebsd-hackers_at_freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscribe_at_freebsd.org"Received on Thu Mar 16 2006 - 13:25:39 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:53 UTC