Re: ZFS...
You might look at UFS Explorer. It claims to have ZFS support now. It costs money for a license and I think required windows last I used it. I can attest that a previous version allowed me to recover all the data I needed from a lost UFS mirror almost a decade ago. Sent from my iPhone > On May 7, 2019, at 9:01 PM, Michelle Sullivan wrote: > > Karl Denninger wrote: >>> On 5/7/2019 00:02, Michelle Sullivan wrote: >>> The problem I see with that statement is that the zfs dev mailing lists >>> constantly and consistently following the line of, the data is always right >>> there is no need for a “fsck” (which I actually get) but it’s used to shut >>> down every thread... the irony is I’m now installing windows 7 and SP1 on a >>> usb stick (well it’s actually installed, but sp1 isn’t finished yet) so I >>> can install a zfs data recovery tool which reports to be able to “walk the >>> data” to retrieve all the files... the irony eh... install windows7 on a >>> usb stick to recover a FreeBSD installed zfs filesystem... will let you >>> know if the tool works, but as it was recommended by a dev I’m hopeful... >>> have another array (with zfs I might add) loaded and ready to go... if the >>> data recovery is successful I’ll blow away the original machine and work >>> out what OS and drive setup will be safe for the data in the future. I >>> might even put FreeBSD and zfs back on it, but if I do it won’t be in the >>> current Zraid2 config. >> Meh. >> >> Hardware failure is, well, hardware failure. Yes, power-related >> failures are hardware failures. >> >> Never mind the potential for /software /failures. Bugs are, well, >> bugs. And they're a real thing. Never had the shortcomings of UFS bite >> you on an "unexpected" power loss? Well, I have. Is ZFS absolutely >> safe against any such event? No, but it's safe*r*. > > Yes and no ... I'll explain... > >> >> I've yet to have ZFS lose an entire pool due to something bad happening, >> but the same basic risk (entire filesystem being gone) > > Everytime I have seen this issue (and it's been more than once - though until > now recoverable - even if extremely painful) - its always been during a > resilver of a failed drive and something happening... panic, another drive > failure, power etc.. any other time its rock solid... which is the yes and > no... under normal circumstances zfs is very very good and seems as safe as > or safer than UFS... but my experience is ZFS has one really bad flaw.. if > there is a corruption in the metadata - even if the stored data is 100% > correct - it will fault the pool and thats it it's gone barring some luck and > painful recovery (backups aside) ... this other file systems also suffer but > there are tools that *majority of the time* will get you out of the s**t with > little pain. Barring this windows based tool I haven't been able to run yet, > zfs appears to have nothing. > >> has occurred more >> than once in my IT career with other filesystems -- including UFS, lowly >> MSDOS and NTFS, never mind their predecessors all the way back to floppy >> disks and the first 5Mb Winchesters. > > Absolutely, been there done that.. and btrfs...*ouch* still as bad.. however > with the only one btrfs install I had (I didn't knopw it was btrfs > underneath, but netgear NAS...) I was still able to recover the data even > though it had screwed the file system so bad I vowed never to consider or use > it again on anything ever... > >> >> I learned a long time ago that two is one and one is none when it comes >> to data, and WHEN two becomes one you SWEAT, because that second failure >> CAN happen at the worst possible time. > > and does.. > >> >> As for RaidZ2 .vs. mirrored it's not as simple as you might think. >> Mirrored vdevs can only lose one member per mirror set, unless you use >> three-member mirrors. That sounds insane but actually it isn't in >> certain circumstances, such as very-read-heavy and high-performance-read >> environments. > > I know - this is why I don't use mirrored - because wear patterns will ensure > both sides of the mirror are closely matched. > >> >> The short answer is that a 2-way mirrored set is materially faster on >> reads but has no acceleration on writes, and can lose one member per >> mirror. If the SECOND one fails before you can resilver, and that >> resilver takes quite a long while if the disks are large, you're dead. >> However, if you do six drives as a 2x3 way mirror (that is, 3 vdevs each >> of a 2-way mirror) you now have three parallel data paths going at once >> and potentially six for reads -- and performance is MUCH better. A >> 3-way mirror can lose two members (and could be organized as 3x2) but >> obviously requires lots of drive slots, 3x as much *power* per gigabyte >> stored (and you pay for power twice; once to buy it and again to get the >> heat out of the room where the machine is.) > > my problem (as always) is slots not
Re: CFT: FreeBSD Package Base
With CFT version you chose to build, and package individual components such as sendmail with a port option. That does entirely solve the problem of being able to reinstall sendmail after the fact without a rebuild of the userland (base) port but perhaps base flavors could solve that problem assuming flavors could extend beyond python. Joe Maloney Quality Engineering Manager / iXsystems Enterprise Storage & Servers Driven By Open Source > On Apr 29, 2019, at 3:31 PM, Cy Schubert wrote: > > In message <201904291441.x3tefmid072...@gndrsh.dnsmgr.net>, "Rodney W. > Grimes" > writes: >>> On Mon, Apr 29, 2019 at 10:09 AM Rodney W. Grimes < >>> freebsd-...@gndrsh.dnsmgr.net> wrote: >>> >>>>> >>>>> Correct, this is ZFS only. And it's something we're using specific to >>>> FreeNAS / TrueOS, which is why I didn't originally mention it as apart of >>>> our CFT. >>>> >>>> Then please it is "CFT: FreeNAS/TrueOS pkg base, ZFS only", >>>> calling this FreeBSD pkg base when it is not was wrong, >>>> and miss leading. >>>> >>> >>> Sorry, I disagree. >> Which is fine. >> >>> This pkg base is independent of the ZFS tool we're using >>> to wrangle boot-environments. Hence why it wasn't mentioned in the CFT. >>> These base packages work the same as existing in-tree pkg base on UFS, no >>> difference. If anything are probably safer due to being able to update all >>> of userland in single extract operation, so you don't have out of order >>> extraction of libc or some such. >> >> You missed the major string change and focused on the edge, >> No comment on calling iXsystems :stuff: FreeBSD instead of FreeNAS/TrueOS? >> >> That was the major point of my statement, your miss leading the user >> community, you yourself said this would never be imported into FreeBSD >> base, so I see no reason that it should be called "FreeBSD package Base", >> as it is not, that is a different project. > > Taking the last comment on this thread to ask a question and maybe > refocus a little. > > The discussion about granularity begs the question, why pkgbase in the > first place? My impression was that it allowed people to select which > components they wanted to either create a lean installation or mix and > match base packages and ports (possibly with flavours to install in > /usr rather than $LOCALBASE) such that maybe person A wanted a stock > install while person B wanted to replace, picking a random example, BSD > tar with GNU tar. Isn't that the real advantage of pkgbase? > > If OTOH it's binary updates V 2.0, what's the point? I'm a little > rhetorical here but you get my point. If I want ipfw instead pf or > ipfilter instead of the others I should have the freedom. Similarly if > I want vim instead of vi I should have the choice to install vim as > /usr/bin/vi. Otherwise all the effort to replace binary updates makes > no sense. > > > -- > Cheers, > Cy Schubert > FreeBSD UNIX: Web: http://www.FreeBSD.org > > The need of the many outweighs the greed of the few. > > > ___ > freebsd-curr...@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: drm / drm2 removal in 12
Thanks for the drm-next efforts. I could not, and would not be using FreeBSD without it. Joe Maloney On Mon, Aug 27, 2018 at 5:58 AM Thomas Mueller wrote: > Excerpt from Oliver Pinter: > > > Let's do some more step backwards, and see how the graphics driver > > developments works from the corporation side. > > They not bother about any of the BSDs, they focus only to Windows and > > Linux. If you want to use a recent (haha recent, something after 2014) > you > > are forced to use new drivers from linux. > > The fore/advantage on the Linux side are the zillions of corporately paid > > kernel developers. > > They can just focus on a new hw supports, on freebsd side, there are no > > corporately paid drm driver developer. Sadly. > > In linux word their internal KPI (try a Google for a "stable API > nonsense" > > words) moves so fastly, that porting of these drivers gets non trivial > > without a dedicated paid team. > > > If you want to change on this situation, try to learn for you could help > or > > send directed donations to freebsd foundation. ;) > > Linux and FreeBSD are not the only open-source OSes. > > There is also (Net, Open, DragonFly)BSD, Haiku, OpenIndiana and others. > > Maybe better would be for the hardware manufacturers to release more > general specifications that could be adapted to any OS, by the NetBSD > developers, Haiku developers, etc. Certainly not to ignore Linux. > > Tom > > ___ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
