Re: Periodic jobs triggering panics in 10.1 and 10.2

[Andriy Gapon]

On 10/12/2015 05:38, Karl Denninger wrote:
> Beadm allows you to set the "next boot" and works as expected.
> 
> You can't select from the boot loader but you can certainly ping-pong
> between a working and test environment easily (I do this all the time)

Being able to easily switch between BEs during boot is a part of the BE
experience.  Think of a situation where a new BE gets a kernel panic half way
through the boot process.

-- 
Andriy Gapon
___
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: Periodic jobs triggering panics in 10.1 and 10.2

[Michelle Sullivan]

Michael B. Eichorn wrote:
>
> I sorry, but I really don't get your point, PCBSD has shown a great
> reason why zfs on root and on laptops/desktops is a good idea... boot
>   

It has?  As this is FreeBSD not PCBSD I must have missed that one...


> environments. They have pretty much figured out how to use snapshots to
> go from A-B ping-pong installations to A-B-C-D-E installations. I
> am even aware of people using it to run Release and Current on the same
> machine. Unfortunately at the moment the system requires GRUB, but
> there is ongoing work to add the ability to the FreeBSD bootloader.
>   

But it's not there yet... and would you consider this for someone who is
not that technical?  (Not that technical != non technical)


> Further IIRC zfs send-receive has a history involving a developer who
> wanted a better rsync for transfering his work to a laptop.

As I said previously these are the features are the ones you listed as
'additional' (ie your after thoughts)


>  In addition
> we have pretty much Moore's Lawed our way to the point where a new
> laptop today can out spec a typical server from when ZFS was first
> implemented.
>   

I have yet to see a 6 spindle laptop...  in fact I've yet to see a 3+
spindle laptop...

I could be recalling wrongly but I'm pretty sure a number of emails have
been seen on @freebsd.org lists that say, "don't use zfs on single
spindle machines"..  what I do know is that personally I have a machine
with a hardware RAID and 16 drives...  Initially I configured it with 1
large LD RAID6+HSP and put zfs on it (because I wanted to take advantage
of the 'on the fly compression')... it's a backup store... and every
scrub checksum errors were found - on files that had not been written to
since the last scrub.  I reconfigured it as 16 x single disk RAID0
drives - identical hardware, just a different config, put raidz2 across
15 drives and left one as a spare and now I don't have any errors except
when a drive fails and even then it 'self heals'...


> Hiding features because you 'can' shoot your foot off is hardly a
> typical UNIXy way of thinking anyway.

Not talking about 'hiding' features, even though this thread started
with someone suggesting 'hiding' a bug by using -J and -j options for
cron!

Look I'm being quite confrontational here in this message, there are a
lot of people that don't like me here, and I don't like some of them
myself so the feeling is very mutual, the point I'm trying to make is
quite simple.

I see it almost daily, FreeBSD people saying "install ZFS that'll solve
your problems" and "ZFS it's the way forward" ...  just the same way as
they did with PkgNG etc... (not going to say anything on that, don't
want an argument on that, this is not about 'that'..)

ZFS has it's place, it is very good at some things, it brings features
that people need.
ZFS does not work (is not stable) on i386 without recompiling the
kernel, but it is presented as an installation option.
ZFS is compiled in by default in i386 kernels without the necessary
option change to make it "stable".
We have been told the kernel option change will never be put there by
default.
freebsd-update will remove/replace a kernel compiled with the option
i386 is still a teir1 platform.
32bit laptops are still available for purchase at major retailers (eg:
Bestbuy)

I do not believe zfs should be default available when it is not stable
on all teir1 platforms.  I believe it should be fixed to be stable
before its added as an installation option to teir1 platforms and if it
cannot/willnot be fixed to 'stable' status then it should never make it
into the defaults available... it should be limited to be in advanced
installations where the people who know will probably know how to fix
things or what to expect.

..anyhow my thoughts on the subject..  why I don't know because in the
time it has taken me to write this, it occurred to me, I don't give a
stuff really if people see FreeBSD as stable or unstable anymore.  I put
forward experiences and what I see and the questions/answers I have to
deal with here and am usually ignored or argued with and I spend 30
minutes (or more) writing emails explaining stuff/defending myself to
people who don't care and think (like me) they know best when I could
actually be doing the work I get paid for.  On that note I will leave
you to considerand discard my thoughts as trivial and pointless and
reply as such and get on with making my stuff better by actually
listening to people who use it.


-- 
Michelle Sullivan
http://www.mhix.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: Periodic jobs triggering panics in 10.1 and 10.2

[Karl Denninger]

On 12/10/2015 02:40, Andriy Gapon wrote:
> On 10/12/2015 05:38, Karl Denninger wrote:
>> Beadm allows you to set the "next boot" and works as expected.
>>
>> You can't select from the boot loader but you can certainly ping-pong
>> between a working and test environment easily (I do this all the time)
> Being able to easily switch between BEs during boot is a part of the BE
> experience.  Think of a situation where a new BE gets a kernel panic half way
> through the boot process.
>
Yeah, that's why I have a USB drive plugged into an (internal)
motherboard connector with a known-bootable image on it, maintained to a
sufficient level to work with whatever might otherwise hose me (e.g. ZFS
version flags)  :-=) 

Yes, I've needed it in anger before :->

-- 
Karl Denninger
k...@denninger.net 
/The Market Ticker/
/[S/MIME encrypted email preferred]/


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Periodic jobs triggering panics in 10.1 and 10.2

[Kurt Jaeger]

Hi!

> I could be recalling wrongly but I'm pretty sure a number of emails have
> been seen on @freebsd.org lists that say, "don't use zfs on single
> spindle machines"

We do ZFS on single-spindle/SSD devices regularly. No problems
as of now.

-- 
p...@opsec.eu+49 171 3101372 5 years to go !
___
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: Periodic jobs triggering panics in 10.1 and 10.2

[Michael B. Eichorn]

On Thu, 2015-12-10 at 14:16 +0100, Michelle Sullivan wrote:
> Michael B. Eichorn wrote:
> > 
> > I sorry, but I really don't get your point, PCBSD has shown a great
> > reason why zfs on root and on laptops/desktops is a good idea...
> > boot
> >   
> 
> It has?  As this is FreeBSD not PCBSD I must have missed that one...

PCBSD is effectively a 'distribution' of FreeBSD, It is just a
different set of defaults and packages with different options. I mean
you can make a FreeBSD install PCBSD by swapping out th repo. I think
using them as an example is within reason.

> > environments. They have pretty much figured out how to use
> > snapshots to
> > go from A-B ping-pong installations to A-B-C-D-E installations.
> > I
> > am even aware of people using it to run Release and Current on the
> > same
> > machine. Unfortunately at the moment the system requires GRUB, but
> > there is ongoing work to add the ability to the FreeBSD bootloader.
> >   
> 
> But it's not there yet... and would you consider this for someone who
> is
> not that technical?  (Not that technical != non technical)

I will concede that until the bootloader work is done I would not
recommend boot environments to a less technical user.

> > Further IIRC zfs send-receive has a history involving a developer
> > who
> > wanted a better rsync for transfering his work to a laptop.
> 
> As I said previously these are the features are the ones you listed
> as
> 'additional' (ie your after thoughts)

It wasn't me in the previous email, but if there is any marginal
benifit over UFS for a laptop/desktop it is probably send-receive.

> 
> 
> >  In addition
> > we have pretty much Moore's Lawed our way to the point where a new
> > laptop today can out spec a typical server from when ZFS was first
> > implemented.
> >   
> 
> I have yet to see a 6 spindle laptop...  in fact I've yet to see a 3+
> spindle laptop...

Your are correct here, I was mostly tring to point out the CPU and RAM
on client machines are now up to what servers were at. That said, I
have been running mirrored SSDs since it became an option.

> I could be recalling wrongly but I'm pretty sure a number of emails
> have
> been seen on @freebsd.org lists that say, "don't use zfs on single
> spindle machines"..  what I do know is that personally I have a
> machine
> with a hardware RAID and 16 drives...  Initially I configured it with
> 1
> large LD RAID6+HSP and put zfs on it (because I wanted to take
> advantage
> of the 'on the fly compression')... it's a backup store... and every
> scrub checksum errors were found - on files that had not been written
> to
> since the last scrub.  I reconfigured it as 16 x single disk RAID0
> drives - identical hardware, just a different config, put raidz2
> across
> 15 drives and left one as a spare and now I don't have any errors
> except
> when a drive fails and even then it 'self heals'...

Hmm, the advice that ZFS advocates such a Allan Jude have been giving
of late is that ZFS can work in single spindle. It is just that it is
less safe (like any single disk) but is not more data-loss prone than
other forms of striping.

> > Hiding features because you 'can' shoot your foot off is hardly a
> > typical UNIXy way of thinking anyway.
> 
> Not talking about 'hiding' features, even though this thread started
> with someone suggesting 'hiding' a bug by using -J and -j options for
> cron!

I will fess up, It was me who suggested -J and -j, but it was more in
the sense of improving the work-around (the OP had just stopped running
cron in jails). It was not ment to imply the bug shouldn't be fixed,
all bugs should be fixed and not hidden.

> Look I'm being quite confrontational here in this message, there are
> a
> lot of people that don't like me here, and I don't like some of them
> myself so the feeling is very mutual, the point I'm trying to make is
> quite simple.

I must admit to being a bit 'heated' too, but I kind of like debates
and I take no personal grievance, or have any problem with you. It is a
technical discussion with strongly held beliefs. Further despite the
emotions I applaud the continued use of professional language.

> I see it almost daily, FreeBSD people saying "install ZFS that'll
> solve
> your problems" and "ZFS it's the way forward" ...  just the same way
> as
> they did with PkgNG etc... (not going to say anything on that, don't
> want an argument on that, this is not about 'that'..)
> 
> ZFS has it's place, it is very good at some things, it brings
> features
> that people need.
> ZFS does not work (is not stable) on i386 without recompiling the
> kernel, but it is presented as an installation option.
> ZFS is compiled in by default in i386 kernels without the necessary
> option change to make it "stable".
> We have been told the kernel option change will never be put there by
> default.
> freebsd-update will remove/replace a kernel compiled with the option
> i386 is still a teir1 platform.
> 32bit laptops are still 

Re: Periodic jobs triggering panics in 10.1 and 10.2

[Michael Jung]

On 2015-12-10 09:45, Michael B. Eichorn wrote:

On Thu, 2015-12-10 at 14:16 +0100, Michelle Sullivan wrote:

Michael B. Eichorn wrote:
>
> I sorry, but I really don't get your point, PCBSD has shown a great
> reason why zfs on root and on laptops/desktops is a good idea...
> boot
>  

It has?  As this is FreeBSD not PCBSD I must have missed that one...


PCBSD is effectively a 'distribution' of FreeBSD, It is just a
different set of defaults and packages with different options. I mean
you can make a FreeBSD install PCBSD by swapping out th repo. I think
using them as an example is within reason.


> environments. They have pretty much figured out how to use
> snapshots to
> go from A-B ping-pong installations to A-B-C-D-E installations.
> I
> am even aware of people using it to run Release and Current on the
> same
> machine. Unfortunately at the moment the system requires GRUB, but
> there is ongoing work to add the ability to the FreeBSD bootloader.
>  

But it's not there yet... and would you consider this for someone who
is
not that technical?  (Not that technical != non technical)


I will concede that until the bootloader work is done I would not
recommend boot environments to a less technical user.


> Further IIRC zfs send-receive has a history involving a developer
> who
> wanted a better rsync for transfering his work to a laptop.

As I said previously these are the features are the ones you listed
as
'additional' (ie your after thoughts)


It wasn't me in the previous email, but if there is any marginal
benifit over UFS for a laptop/desktop it is probably send-receive.




>  In addition
> we have pretty much Moore's Lawed our way to the point where a new
> laptop today can out spec a typical server from when ZFS was first
> implemented.
>  

I have yet to see a 6 spindle laptop...  in fact I've yet to see a 3+
spindle laptop...


Your are correct here, I was mostly tring to point out the CPU and RAM
on client machines are now up to what servers were at. That said, I
have been running mirrored SSDs since it became an option.


I could be recalling wrongly but I'm pretty sure a number of emails
have
been seen on @freebsd.org lists that say, "don't use zfs on single
spindle machines"..  what I do know is that personally I have a
machine
with a hardware RAID and 16 drives...  Initially I configured it with
1
large LD RAID6+HSP and put zfs on it (because I wanted to take
advantage
of the 'on the fly compression')... it's a backup store... and every
scrub checksum errors were found - on files that had not been written
to
since the last scrub.  I reconfigured it as 16 x single disk RAID0
drives - identical hardware, just a different config, put raidz2
across
15 drives and left one as a spare and now I don't have any errors
except
when a drive fails and even then it 'self heals'...


Hmm, the advice that ZFS advocates such a Allan Jude have been giving
of late is that ZFS can work in single spindle. It is just that it is
less safe (like any single disk) but is not more data-loss prone than
other forms of striping.


> Hiding features because you 'can' shoot your foot off is hardly a
> typical UNIXy way of thinking anyway.

Not talking about 'hiding' features, even though this thread started
with someone suggesting 'hiding' a bug by using -J and -j options for
cron!


I will fess up, It was me who suggested -J and -j, but it was more in
the sense of improving the work-around (the OP had just stopped running
cron in jails). It was not ment to imply the bug shouldn't be fixed,
all bugs should be fixed and not hidden.


Look I'm being quite confrontational here in this message, there are
a
lot of people that don't like me here, and I don't like some of them
myself so the feeling is very mutual, the point I'm trying to make is
quite simple.


I must admit to being a bit 'heated' too, but I kind of like debates
and I take no personal grievance, or have any problem with you. It is a
technical discussion with strongly held beliefs. Further despite the
emotions I applaud the continued use of professional language.


I see it almost daily, FreeBSD people saying "install ZFS that'll
solve
your problems" and "ZFS it's the way forward" ...  just the same way
as
they did with PkgNG etc... (not going to say anything on that, don't
want an argument on that, this is not about 'that'..)

ZFS has it's place, it is very good at some things, it brings
features
that people need.
ZFS does not work (is not stable) on i386 without recompiling the
kernel, but it is presented as an installation option.
ZFS is compiled in by default in i386 kernels without the necessary
option change to make it "stable".
We have been told the kernel option change will never be put there by
default.
freebsd-update will remove/replace a kernel compiled with the option
i386 is still a teir1 platform.
32bit laptops are still available for purchase at major retailers
(eg:
Bestbuy)


You are correct, ZFS is not a panacia, and they clearly 

Re: Periodic jobs triggering panics in 10.1 and 10.2

[Fabian Keil]

Michelle Sullivan  wrote:

> ZFS has it's place, it is very good at some things, it brings features
> that people need.
> ZFS does not work (is not stable) on i386 without recompiling the
> kernel, but it is presented as an installation option.
> ZFS is compiled in by default in i386 kernels without the necessary
> option change to make it "stable".
> We have been told the kernel option change will never be put there by
> default.

FYI, the stack overflows should be addressed by:
https://svnweb.freebsd.org/base?view=revision=r286288

Fabian


pgpBJ6TnkYrx5.pgp
Description: OpenPGP digital signature

Re: Periodic jobs triggering panics in 10.1 and 10.2

[Jan Bramkamp]

On 09/12/15 01:04, Michael B. Eichorn wrote:

On Tue, 2015-12-08 at 16:31 -0600, Dustin Wenz wrote:

I suspect this is a zfs bug that is triggered by the access patterns
in the periodic scripts. There is significant load on the system when
the scheduled processes start, because all jails execute the same
scripts at the same time.

I've been able to alleviate this problem by disabling the security
scans within the jails, but leave it enabled on the root host.


To avoid the problem of jails all starting things at the same time, use
the cron(8) flags -j and -J to set a 'jitter' which will cause cron to
sleep for a random period of specified duration (60 sec max). Cron
flags can be set using the rc.conf variable 'cron_flags'.


While jitter would reduce the resource contention a thundering herd of 
cronjobs shouldn't cause the kernel to divide by zero. Spreading the 
load by introducing jitter to cronjobs might hide the problem, but it 
still needs further analysis.


@Dustin Wenz: Can you reproduce the problem and file a PR to track this?
___
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: Periodic jobs triggering panics in 10.1 and 10.2

[Jan Bramkamp]

On 09/12/15 13:45, Michelle Sullivan wrote:

Michael B. Eichorn wrote:

On Tue, 2015-12-08 at 16:31 -0600, Dustin Wenz wrote:


I suspect this is a zfs bug that is triggered by the access patterns
in the periodic scripts. There is significant load on the system when
the scheduled processes start, because all jails execute the same
scripts at the same time.

I've been able to alleviate this problem by disabling the security
scans within the jails, but leave it enabled on the root host.



To avoid the problem of jails all starting things at the same time, use
the cron(8) flags -j and -J to set a 'jitter' which will cause cron to
sleep for a random period of specified duration (60 sec max). Cron
flags can be set using the rc.conf variable 'cron_flags'.
___



No that will just hide it (if successful at all) and it won't work in
all cases.

... i386 is even worse for similar (not the same) instability triggered
by the same scripts ... because zfs should not be used with the stock
i386 kernel (which means if you're using it the whole patching process
with freebsd-update won't work or will 'undo' your kernel config.)


Do you have a good idea how to prevent users from shooting themselves in 
the foot by running ZFS on 32 Bit kernels?



Personally I think zfs should be optional only for 'advanced' users and
come with a whole host of warnings about what it is not suitable for
however, it seems to be treated as a magic bullet for data corruption
issues yet all I have seen is an ever growing list of where it causes
problems.. when did UFS become an unreliable FS that is susceptible to
chronic data corruption?


As storage capacity grew a lot faster than reliability.

UFS is a good file system for its time, but it trusts hardware 
absolutely. Modern hardware doesn't deserve this level of trust. ZFS 
detects and recovers without dataloss from most errors caused by the 
limited hardware reliability.


ZFS isn't just a tool to deal with hardware limitations it's also a 
convenience I no longer want to give up. Snapshots and replication 
streams simplify backups and a background scrub once a week (or month) 
sure beats waiting for fsck.

___
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: Periodic jobs triggering panics in 10.1 and 10.2

[Michelle Sullivan]

Michael B. Eichorn wrote:
> On Tue, 2015-12-08 at 16:31 -0600, Dustin Wenz wrote:
>   
>> I suspect this is a zfs bug that is triggered by the access patterns
>> in the periodic scripts. There is significant load on the system when
>> the scheduled processes start, because all jails execute the same
>> scripts at the same time.
>>
>> I've been able to alleviate this problem by disabling the security
>> scans within the jails, but leave it enabled on the root host.
>> 
>
> To avoid the problem of jails all starting things at the same time, use
> the cron(8) flags -j and -J to set a 'jitter' which will cause cron to
> sleep for a random period of specified duration (60 sec max). Cron
> flags can be set using the rc.conf variable 'cron_flags'.
> ___
>   

No that will just hide it (if successful at all) and it won't work in
all cases.

... i386 is even worse for similar (not the same) instability triggered
by the same scripts ... because zfs should not be used with the stock
i386 kernel (which means if you're using it the whole patching process
with freebsd-update won't work or will 'undo' your kernel config.)

Personally I think zfs should be optional only for 'advanced' users and
come with a whole host of warnings about what it is not suitable for
however, it seems to be treated as a magic bullet for data corruption
issues yet all I have seen is an ever growing list of where it causes
problems.. when did UFS become an unreliable FS that is susceptible to
chronic data corruption?

-- 
Michelle Sullivan
http://www.mhix.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: Periodic jobs triggering panics in 10.1 and 10.2

[Michael B. Eichorn]

On Wed, 2015-12-09 at 11:24 +0100, Jan Bramkamp wrote:
> 
> On 09/12/15 01:04, Michael B. Eichorn wrote:
> > On Tue, 2015-12-08 at 16:31 -0600, Dustin Wenz wrote:
> > > I suspect this is a zfs bug that is triggered by the access
> > > patterns
> > > in the periodic scripts. There is significant load on the system
> > > when
> > > the scheduled processes start, because all jails execute the same
> > > scripts at the same time.
> > > 
> > > I've been able to alleviate this problem by disabling the
> > > security
> > > scans within the jails, but leave it enabled on the root host.
> > 
> > To avoid the problem of jails all starting things at the same time,
> > use
> > the cron(8) flags -j and -J to set a 'jitter' which will cause cron
> > to
> > sleep for a random period of specified duration (60 sec max). Cron
> > flags can be set using the rc.conf variable 'cron_flags'.
> 
> While jitter would reduce the resource contention a thundering herd
> of 
> cronjobs shouldn't cause the kernel to divide by zero. Spreading the 
> load by introducing jitter to cronjobs might hide the problem, but it
> still needs further analysis.

I concur, used the word 'avoid' in the sense that this was an
improvement to his work-around (which is all that I quoted). I had no
intent to imply that it was the solution to the bug, which of course
deserves solving. Sorry for any confusion, I will try to be more clear
in the future.

smime.p7s
Description: S/MIME cryptographic signature

Re: Periodic jobs triggering panics in 10.1 and 10.2

[Michelle Sullivan]

Jan Bramkamp wrote:
> On 09/12/15 13:45, Michelle Sullivan wrote:
>>
>> No that will just hide it (if successful at all) and it won't work in
>> all cases.
>>
>> ... i386 is even worse for similar (not the same) instability triggered
>> by the same scripts ... because zfs should not be used with the stock
>> i386 kernel (which means if you're using it the whole patching process
>> with freebsd-update won't work or will 'undo' your kernel config.)
>
> Do you have a good idea how to prevent users from shooting themselves
> in the foot by running ZFS on 32 Bit kernels?

Yes default not to having zfs available on any platform and allow people
that know what they are doing to turn it on  I mean "prevent users
from shooting themselves in the foot" - how about by not having an
option to install a zfs root on the default install disks?

>
>> Personally I think zfs should be optional only for 'advanced' users and
>> come with a whole host of warnings about what it is not suitable for
>> however, it seems to be treated as a magic bullet for data corruption
>> issues yet all I have seen is an ever growing list of where it causes
>> problems.. when did UFS become an unreliable FS that is susceptible to
>> chronic data corruption?
>
> As storage capacity grew a lot faster than reliability.

Yeah, that's why we have these multi-tes-of-terrabyte laptops that must
have a zfs root install...

>
> UFS is a good file system for its time, but it trusts hardware
> absolutely. Modern hardware doesn't deserve this level of trust.

Ok at this point we have to question things...

Does your average home machine need zfs?  (because windows doesn't) ...
does your average laptop require zfs (or even benefit) ...?   In fact
when I look at it, I'm running  70+ servers and a few desktops and I'm
running 5 of them with zfs...  2 of them absolutely need it, 2 of them
are solaris (which probably doesn't count and certainly doesn't have
relevance to FreeBSD) the other is a 2005 P4 based server that is
completely unusable because zfs on i386 doesn't work with the stock
kernel  and guess what ... it has 73G 15k SCSI Server drives in it
so it probably has reliable hardware that doesn't suffer from "Modern
hardware doesn't deserve this level of trust"

> ZFS detects and recovers without dataloss from most errors caused by
> the limited hardware reliability.

Currently I've had more problems with the reliability of zfs in FreeBSD
than reliability of hardware..  I do get your point though...

>
> ZFS isn't just a tool to deal with hardware limitations it's also a
> convenience I no longer want to give up. Snapshots and replication
> streams simplify backups and a background scrub once a week (or month)
> sure beats waiting for fsck.
Now this is the one set of reasons I can really appreciate and had it
been the opening argument I'd have understood your position, but it
seems this is a side note to the above and the above is where I see it's
completely useless...  When ZFS was first developed a friend and I in
Sun had lots of fun setting up servers where we just chucked any old
drives we could lay our hands on into a pool ... this we found very cool
and this was where 'unreliable' hardware was an understatement - the
drives were pulled from machines because SMART (and other tools) were
reporting the drive(s) failing. but it was a work around for bad
sectors etc...

Seriously though the default to install with zfs and root on zfs is a
really bad idea - the people who know how not to shoot themselves in the
foot are those people that don't need a selectable option in the install
because they know how to configure it... they're the people who will
probably be in every manual and advanced option they can find anyhow (or
just using boot servers and predefined install scripts)!!

Regards,

-- 
Michelle Sullivan
http://www.mhix.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: Periodic jobs triggering panics in 10.1 and 10.2

[Michael B. Eichorn]

On Wed, 2015-12-09 at 23:26 +0100, Michelle Sullivan wrote:
> Jan Bramkamp wrote:
> > On 09/12/15 13:45, Michelle Sullivan wrote:
> > > 
> > > No that will just hide it (if successful at all) and it won't
> > > work in
> > > all cases.
> > > 
> > > ... i386 is even worse for similar (not the same) instability
> > > triggered
> > > by the same scripts ... because zfs should not be used with the
> > > stock
> > > i386 kernel (which means if you're using it the whole patching
> > > process
> > > with freebsd-update won't work or will 'undo' your kernel
> > > config.)
> > 
> > Do you have a good idea how to prevent users from shooting
> > themselves
> > in the foot by running ZFS on 32 Bit kernels?
> 
> Yes default not to having zfs available on any platform and allow
> people
> that know what they are doing to turn it on  I mean "prevent
> users
> from shooting themselves in the foot" - how about by not having an
> option to install a zfs root on the default install disks?
> 
> > 
> > > Personally I think zfs should be optional only for 'advanced'
> > > users and
> > > come with a whole host of warnings about what it is not suitable
> > > for
> > > however, it seems to be treated as a magic bullet for data
> > > corruption
> > > issues yet all I have seen is an ever growing list of where it
> > > causes
> > > problems.. when did UFS become an unreliable FS that is
> > > susceptible to
> > > chronic data corruption?
> > 
> > As storage capacity grew a lot faster than reliability.
> 
> Yeah, that's why we have these multi-tes-of-terrabyte laptops that
> must
> have a zfs root install...
> 
> > 
> > UFS is a good file system for its time, but it trusts hardware
> > absolutely. Modern hardware doesn't deserve this level of trust.
> 
> Ok at this point we have to question things...
> 
> Does your average home machine need zfs?  (because windows doesn't)
> ...
> does your average laptop require zfs (or even benefit) ...?   In fact
> when I look at it, I'm running  70+ servers and a few desktops and
> I'm
> running 5 of them with zfs...  2 of them absolutely need it, 2 of
> them
> are solaris (which probably doesn't count and certainly doesn't have
> relevance to FreeBSD) the other is a 2005 P4 based server that is
> completely unusable because zfs on i386 doesn't work with the stock
> kernel  and guess what ... it has 73G 15k SCSI Server drives in
> it
> so it probably has reliable hardware that doesn't suffer from "Modern
> hardware doesn't deserve this level of trust"
> 
> > ZFS detects and recovers without dataloss from most errors caused
> > by
> > the limited hardware reliability.
> 
> Currently I've had more problems with the reliability of zfs in
> FreeBSD
> than reliability of hardware..  I do get your point though...
> 
> > 
> > ZFS isn't just a tool to deal with hardware limitations it's also a
> > convenience I no longer want to give up. Snapshots and replication
> > streams simplify backups and a background scrub once a week (or
> > month)
> > sure beats waiting for fsck.
> Now this is the one set of reasons I can really appreciate and had it
> been the opening argument I'd have understood your position, but it
> seems this is a side note to the above and the above is where I see
> it's
> completely useless...  When ZFS was first developed a friend and I in
> Sun had lots of fun setting up servers where we just chucked any old
> drives we could lay our hands on into a pool ... this we found very
> cool
> and this was where 'unreliable' hardware was an understatement - the
> drives were pulled from machines because SMART (and other tools) were
> reporting the drive(s) failing. but it was a work around for bad
> sectors etc...
> 
> Seriously though the default to install with zfs and root on zfs is a
> really bad idea - the people who know how not to shoot themselves in
> the
> foot are those people that don't need a selectable option in the
> install
> because they know how to configure it... they're the people who will
> probably be in every manual and advanced option they can find anyhow
> (or
> just using boot servers and predefined install scripts)!!
> 
> Regards,
> 

I sorry, but I really don't get your point, PCBSD has shown a great
reason why zfs on root and on laptops/desktops is a good idea... boot
environments. They have pretty much figured out how to use snapshots to
go from A-B ping-pong installations to A-B-C-D-E installations. I
am even aware of people using it to run Release and Current on the same
machine. Unfortunately at the moment the system requires GRUB, but
there is ongoing work to add the ability to the FreeBSD bootloader.

Further IIRC zfs send-receive has a history involving a developer who
wanted a better rsync for transfering his work to a laptop. In addition
we have pretty much Moore's Lawed our way to the point where a new
laptop today can out spec a typical server from when ZFS was first
implemented.

Hiding features because you 'can' shoot your foot 

Re: Periodic jobs triggering panics in 10.1 and 10.2

[Freddie Cash]

On Dec 9, 2015 7:24 PM, "Karl Denninger"  wrote:
>
> On 12/9/2015 17:29, Michael B. Eichorn wrote:
> > I sorry, but I really don't get your point, PCBSD has shown a great
> > reason why zfs on root and on laptops/desktops is a good idea... boot
> > environments. They have pretty much figured out how to use snapshots
> > to go from A-B ping-pong installations to A-B-C-D-E installations.
> > I am even aware of people using it to run Release and Current on the
> > same machine. Unfortunately at the moment the system requires GRUB,
> > but there is ongoing work to add the ability to the FreeBSD
> > bootloader. Further IIRC zfs send-receive has a history involving a
> > developer who wanted a better rsync for transfering his work to a
> > laptop. In addition we have pretty much Moore's Lawed our way to the
> > point where a new laptop today can out spec a typical server from when
> > ZFS was first implemented. Hiding features because you 'can' shoot
> > your foot off is hardly a typical UNIXy way of thinking anyway.
>
> Boot environments work fine on FreeBSD.  Look at "beadm" :-)
>
> What are you trying to do that you need GRUB?

GRUB supports listing and selecting boot environments as part of the boot
process.

FreeBSD 8.x and 9.x boot loaders don't support listing or selecting BEs.
Neither does 10.0; not sure about 10.1.

Devin Teske and company did a lot of work on this area, and I believe 10.2,
certainly -CURRENT, supports this.

Because of BEs, PC-BSD flip-flopped between the FreeBSD loader and GRUB in
the 9.x and 10.x releases. I think they support both now.

Typos courtesy of my phone's autocorrect.
___
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: Periodic jobs triggering panics in 10.1 and 10.2

[Karl Denninger]

On 12/9/2015 17:29, Michael B. Eichorn wrote:
> I sorry, but I really don't get your point, PCBSD has shown a great
> reason why zfs on root and on laptops/desktops is a good idea... boot
> environments. They have pretty much figured out how to use snapshots
> to go from A-B ping-pong installations to A-B-C-D-E installations.
> I am even aware of people using it to run Release and Current on the
> same machine. Unfortunately at the moment the system requires GRUB,
> but there is ongoing work to add the ability to the FreeBSD
> bootloader. Further IIRC zfs send-receive has a history involving a
> developer who wanted a better rsync for transfering his work to a
> laptop. In addition we have pretty much Moore's Lawed our way to the
> point where a new laptop today can out spec a typical server from when
> ZFS was first implemented. Hiding features because you 'can' shoot
> your foot off is hardly a typical UNIXy way of thinking anyway. 

Boot environments work fine on FreeBSD.  Look at "beadm" :-)

What are you trying to do that you need GRUB?

-- 
Karl Denninger
k...@denninger.net 
/The Market Ticker/
/[S/MIME encrypted email preferred]/


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Periodic jobs triggering panics in 10.1 and 10.2

[Karl Denninger]

On 12/9/2015 21:37, Freddie Cash wrote:
>
>
> On Dec 9, 2015 7:24 PM, "Karl Denninger"  > wrote:
> >
> > On 12/9/2015 17:29, Michael B. Eichorn wrote:
> > > I sorry, but I really don't get your point, PCBSD has shown a great
> > > reason why zfs on root and on laptops/desktops is a good idea... boot
> > > environments. They have pretty much figured out how to use snapshots
> > > to go from A-B ping-pong installations to A-B-C-D-E installations.
> > > I am even aware of people using it to run Release and Current on the
> > > same machine. Unfortunately at the moment the system requires GRUB,
> > > but there is ongoing work to add the ability to the FreeBSD
> > > bootloader. Further IIRC zfs send-receive has a history involving a
> > > developer who wanted a better rsync for transfering his work to a
> > > laptop. In addition we have pretty much Moore's Lawed our way to the
> > > point where a new laptop today can out spec a typical server from when
> > > ZFS was first implemented. Hiding features because you 'can' shoot
> > > your foot off is hardly a typical UNIXy way of thinking anyway.
> >
> > Boot environments work fine on FreeBSD.  Look at "beadm" :-)
> >
> > What are you trying to do that you need GRUB?
>
> GRUB supports listing and selecting boot environments as part of the
> boot process.
>
> FreeBSD 8.x and 9.x boot loaders don't support listing or selecting
> BEs. Neither does 10.0; not sure about 10.1.
>
> Devin Teske and company did a lot of work on this area, and I believe
> 10.2, certainly -CURRENT, supports this.
>
> Because of BEs, PC-BSD flip-flopped between the FreeBSD loader and
> GRUB in the 9.x and 10.x releases. I think they support both now.
>
> Typos courtesy of my phone's autocorrect.
>

Beadm allows you to set the "next boot" and works as expected.

You can't select from the boot loader but you can certainly ping-pong
between a working and test environment easily (I do this all the time)

-- 
Karl Denninger
k...@denninger.net 
/The Market Ticker/
/[S/MIME encrypted email preferred]/


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Periodic jobs triggering panics in 10.1 and 10.2

[Dustin Wenz]

PF filed:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205163

Please let me know if there is any more useful information I can include.

- .Dustin Wenz


> On Dec 9, 2015, at 4:24 AM, Jan Bramkamp  wrote:
> 
> 
> 
> On 09/12/15 01:04, Michael B. Eichorn wrote:
>> On Tue, 2015-12-08 at 16:31 -0600, Dustin Wenz wrote:
>>> I suspect this is a zfs bug that is triggered by the access patterns
>>> in the periodic scripts. There is significant load on the system when
>>> the scheduled processes start, because all jails execute the same
>>> scripts at the same time.
>>> 
>>> I've been able to alleviate this problem by disabling the security
>>> scans within the jails, but leave it enabled on the root host.
>> 
>> To avoid the problem of jails all starting things at the same time, use
>> the cron(8) flags -j and -J to set a 'jitter' which will cause cron to
>> sleep for a random period of specified duration (60 sec max). Cron
>> flags can be set using the rc.conf variable 'cron_flags'.
> 
> While jitter would reduce the resource contention a thundering herd of 
> cronjobs shouldn't cause the kernel to divide by zero. Spreading the load by 
> introducing jitter to cronjobs might hide the problem, but it still needs 
> further analysis.
> 
> @Dustin Wenz: Can you reproduce the problem and file a PR to track this?
> ___
> 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"

Re: Periodic jobs triggering panics in 10.1 and 10.2

[Michael B. Eichorn]

On Tue, 2015-12-08 at 16:31 -0600, Dustin Wenz wrote:
> I suspect this is a zfs bug that is triggered by the access patterns
> in the periodic scripts. There is significant load on the system when
> the scheduled processes start, because all jails execute the same
> scripts at the same time.
> 
> I've been able to alleviate this problem by disabling the security
> scans within the jails, but leave it enabled on the root host.

To avoid the problem of jails all starting things at the same time, use
the cron(8) flags -j and -J to set a 'jitter' which will cause cron to
sleep for a random period of specified duration (60 sec max). Cron
flags can be set using the rc.conf variable 'cron_flags'.
___
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"