zfs discuss - Oct 2008 - Disabling auto-snapshot by default.

How can you disable the auto-snapshot service[s] by default without disabling
the timeslider as well which appears to be the case if you disable the smf
services.

Setting the properly in the root pool is ok except for removable media which I
don''t want to have snapshots taken in the time between plugging the
things in and setting the property.
--
This message posted from opensolaris.org

Chris,

Tim Foster sent out this syntax previously:

zfs set com.sun:auto-snapshot=false dataset

Unless I''m misunderstanding your questions, try this for the dataset
on the removable media device.

Let me know if you have any issues.

I''m tracking the auto snapshot experience...

Cindy


Chris Gerhard wrote:
> How can you disable the auto-snapshot service[s] by default without
disabling the timeslider as well which appears to be the case if you disable the
smf services.
> 
> Setting the properly in the root pool is ok except for removable media
which I don''t want to have snapshots taken in the time between plugging
the things in and setting the property.
> --
> This message posted from opensolaris.org
> _______________________________________________
> zfs-discuss mailing list
> zfs-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Cindy.Swearingen at Sun.COM wrote:
> Chris,
> 
> Tim Foster sent out this syntax previously:
> 
> zfs set com.sun:auto-snapshot=false dataset
There is an obvious race condition here unless I can set the option when 
  I import the pool which I don''t think I can. I suppose the same 
problem will occur when creating new pools.

With auto-snapshot still on are all the snapshots taken as a single 
transaction as they would be with a recursive snapshot?

Alas I''ve had to downgrade as Nautilus is not usable:

http://blogs.sun.com/chrisg/entry/brief_visit_to_build_100


-- 
Chris Gerhard.                                         __o __o __o
Systems TSC Chief Technologist                        _`\<,`\<,`\<,_
Sun Microsystems Limited                             (*)/---/---/ (*)
Phone: +44 (0) 1252 426033 (ext 26033) http://blogs.sun.com/chrisg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3253 bytes
Desc: S/MIME Cryptographic Signature
URL:
<http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20081024/f23f4d26/attachment.bin>

Hi Chris,

Chris Gerhard wrote:
> How can you disable the auto-snapshot service[s] by default without
 > disabling the timeslider
 > as well which appears to be the case if you disable the smf services.

Not sure I follow - time slider depends on the auto-snapshot service to 
take snapshots... (does the nautilus gui disappear if timeslider is 
disabled - if so, that sounds wrong to me)
> Setting the properly in the root pool is ok except for removable media
 > which I don''t want to have snapshots taken in the time between
plugging
 > the things in and setting the property.

You''ll be ok there. The service checks for/sets the property on service
start on any pools that appear on the system: in effect, this means that 
removable media won''t be snapshotted by default until the service 
refreshes. So only media that were inserted and mounted at boot would 
get snapshotted by default (unless the property was already set on those 
pools to tell the service to leave them alone)

btw. I''ve a changset checked in to have the service not take snapshots 
of swap & dump devices, which was broken in nv_100/101. There''s a
known
bug about the service breaking for datasets with spaces in their names, 
I''ve got an ugly fix, but want to have a go at doing a better job of
it.

	cheers,
			tim

Hi Chris,

Chris Gerhard wrote:
> With auto-snapshot still on are all the snapshots taken as a single 
> transaction as they would be with a recursive snapshot?
Yep, it uses "zfs snapshot -r" when it can, degrading to snapshots of 
the individual datasets it can''t recursively snapshot and recursive 
snapshots of the ones it can. (if that makes sense)

The logic to do that works, but is a bit process-heavy right now: I''m 
working on using more ksh builtins instead.

Of course, you can disable the snapshot-based-on-zfs-user-properties 
functionality, and go back to taking snapshots based solely on 
statically listed filesystems (see the service manifest or README file 
and check for the "zfs/fs-name" SMF property)
> Alas I''ve had to downgrade as Nautilus is not usable:
Yow.

	cheers,
			tim

Tim Foster wrote:
> Hi Chris,
> 
> Chris Gerhard wrote:
>> How can you disable the auto-snapshot service[s] by default without
>  > disabling the timeslider
>  > as well which appears to be the case if you disable the smf services.
> 
> Not sure I follow - time slider depends on the auto-snapshot service to 
> take snapshots... (does the nautilus gui disappear if timeslider is 
> disabled - if so, that sounds wrong to me)
This could be my misunderstanding of the parts of this. When I disabled 
the auto-snapshot resulted in timeslider being disabled too. So what 
does the timeslider service do?
> 
>> Setting the properly in the root pool is ok except for removable media
>  > which I don''t want to have snapshots taken in the time
between plugging
>  > the things in and setting the property.
> 
> You''ll be ok there. The service checks for/sets the property on
service
> start on any pools that appear on the system: in effect, this means that 
> removable media won''t be snapshotted by default until the service 
> refreshes. So only media that were inserted and mounted at boot would 
> get snapshotted by default (unless the property was already set on those 
> pools to tell the service to leave them alone)
> 
> btw. I''ve a changset checked in to have the service not take
snapshots
> of swap & dump devices, which was broken in nv_100/101.
There''s a known
> bug about the service breaking for datasets with spaces in their names, 
> I''ve got an ugly fix, but want to have a go at doing a better job
of it.
I''d really like to be able to turn it off by default globally and then 
turn it on in a controlled fashion. If you take snapshots of file 
systems that are targets of zfs send | zfs receive it will prevent the 
back ups working at all and require a lot of manual effort to recover.


-- 
Chris Gerhard.                                         __o __o __o
Systems TSC Chief Technologist                        _`\<,`\<,`\<,_
Sun Microsystems Limited                             (*)/---/---/ (*)
Phone: +44 (0) 1252 426033 (ext 26033) http://blogs.sun.com/chrisg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3253 bytes
Desc: S/MIME Cryptographic Signature
URL:
<http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20081024/6051c31d/attachment.bin>

Chris Gerhard wrote:
> This could be my misunderstanding of the parts of this. When I disabled 
> the auto-snapshot resulted in timeslider being disabled too.
Yep, time-slider depends on auto-snapshot.
> So what does the timeslider service do?
It''s a service written by the desktop guys that adds a root cron job to
monitor available disk space. The cron job fires every 15 minutes. If 
available disk space has gone below a given threshold, it starts 
destroying auto-snapshots until the available disk space exceeds that 
threshold again.

(I agree those two bits of functionality could be seen as independent of 
each other)

The time slider service has a SMF property with a list of services it 
wants to enable on startup, this isn''t quite the traditional SMF 
dependency relationship, but I can''t remember the exact reasoning for 
doing it this way, I think it had something to do with the failure modes 
for each service - Niall would know more I bet.
> I''d really like to be able to turn it off by default globally and
then
> turn it on in a controlled fashion. If you take snapshots of file 
> systems that are targets of zfs send | zfs receive it will prevent the 
> back ups working at all and require a lot of manual effort to recover.
Yep, you can do that. It uses ZFS user properties and respects 
inheritance, so you can do:

# zfs set com.sun:auto-snapshot=false rpool
# zfs set com.sun:auto-snapshot=true rpool/snapshot/this
# zfs set com.sun:auto-snapshot=false rpool/snapshot/this/but-not-this

So we''d get snapshots of rpool/snapshot/this and all of it''s
child
datasets, except the dataset "rpool/snapshot/this/but-not-this"

(I use all the time on our build machines: I take auto snapshots of 
workspaces, but not proto areas or places where ISO images get built)

	cheers,
			tim

Tim Foster wrote:
> 
> Yep, you can do that. It uses ZFS user properties and respects 
> inheritance, so you can do:
> 
> # zfs set com.sun:auto-snapshot=false rpool
> # zfs set com.sun:auto-snapshot=true rpool/snapshot/this
> # zfs set com.sun:auto-snapshot=false rpool/snapshot/this/but-not-this
Not quite.  I want to make the default for all pools imported or not to 
not do this and then turn it on where it makes sense and won''t do harm.
So it would only take a snapshot if auto-snapshot was set to "true".
If
the property is not set then no snapshot.  Obviously property 
inheritance would still be respected so to turn it on you just set the 
property to true in the root of the pool.


-- 
Chris Gerhard.                                         __o __o __o
Systems TSC Chief Technologist                        _`\<,`\<,`\<,_
Sun Microsystems Limited                             (*)/---/---/ (*)
Phone: +44 (0) 1252 426033 (ext 26033) http://blogs.sun.com/chrisg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3253 bytes
Desc: S/MIME Cryptographic Signature
URL:
<http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20081024/98bb73b3/attachment.bin>

Chris Gerhard wrote:
> Not quite.  I want to make the default for all pools imported or not to 
> not do this and then turn it on where it makes sense and won''t do
harm.
Aah I see. That''s the complete opposite of what the desktop folk wanted
then - you want to opt-in, instead of opt-out.

For desktops & laptops, the requirement was for there to be no required 
user action for this stuff to "just work".  For servers, the intent
was
to just have it totally off by default (that is, the SMF service would 
just be disabled)

I''m not sure there''s an easy way to please everyone to be
honest :-/

That said, how often do you import or create pools where this would be 
an issue?  If you''re importing pools you''ve used on such a
system
before, then you''d already have the property set on the root dataset.

If you''re constantly importing brand new pools, then yes,
you''ve got a
point.

	cheers,
			tim

Chris Gerhard wrote:
> Tim Foster wrote:
> 
>>
>> Yep, you can do that. It uses ZFS user properties and respects 
>> inheritance, so you can do:
>>
>> # zfs set com.sun:auto-snapshot=false rpool
>> # zfs set com.sun:auto-snapshot=true rpool/snapshot/this
>> # zfs set com.sun:auto-snapshot=false rpool/snapshot/this/but-not-this
> 
> Not quite.  I want to make the default for all pools imported or not to 
> not do this and then turn it on where it makes sense and won''t do
harm.
> So it would only take a snapshot if auto-snapshot was set to
"true". If
> the property is not set then no snapshot.  Obviously property 
> inheritance would still be respected so to turn it on you just set the 
> property to true in the root of the pool.
I agree completely with Chris on this.  The the property is not present 
it MUST default to being false and MUST not be added as "true" without
the admin intervention.   It is OK for this to be added as true to the 
rpool pool but not IMO to any pool that happens to get imported.

-- 
Darren J Moffat

Tim Foster wrote:
> Chris Gerhard wrote:
>> Not quite.  I want to make the default for all pools imported or not 
>> to not do this and then turn it on where it makes sense and
won''t do
>> harm. 
> 
> Aah I see. That''s the complete opposite of what the desktop folk
wanted
> then - you want to opt-in, instead of opt-out.
> 
> For desktops & laptops, the requirement was for there to be no required
> user action for this stuff to "just work".  For servers, the
intent was
> to just have it totally off by default (that is, the SMF service would 
> just be disabled)
> 
> I''m not sure there''s an easy way to please everyone to be
honest :-/
I''m not sure you are right there. If there was an SMF property that you
set to set the default behaviour and then you set it to true on 
something that looked like a laptop and false otherwise. Or you could 
just turn it on by default for root pools. Indeed the installation could 
set the property.

While on  a desktop being on by default has some value on a server that 
has been upgraded and therefore would have a backup strategy already in 
place it does not.

Do we supply a script to delete all the auto-snapshot snapshots? Is 
there anyway to recognise them apart from by their name?
> 
> That said, how often do you import or create pools where this would be 
> an issue?  If you''re importing pools you''ve used on such
a system
> before, then you''d already have the property set on the root
dataset.
> 
> If you''re constantly importing brand new pools, then yes,
you''ve got a
> point.
You only have to have this mess with one pool which is being uses as the 
target for a backup for the consequences to be horrible. For that reason 
alone it needs to default to off.

Don''t get me wrong. The service is really nice and the gui integration 
looks like it could be a thing of beauty if it can be made to scale. 
Indeed on my daughter''s laptop it looks great. It''s just it
should
default to being off with a really easy way to turn it on rather than 
the other way round.


-- 
Chris Gerhard.                                         __o __o __o
Systems TSC Chief Technologist                        _`\<,`\<,`\<,_
Sun Microsystems Limited                             (*)/---/---/ (*)
Phone: +44 (0) 1252 426033 (ext 26033) http://blogs.sun.com/chrisg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3253 bytes
Desc: S/MIME Cryptographic Signature
URL:
<http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20081027/92c02590/attachment.bin>

Yup, I''d agree with that too.

If the desktop guys want snapshotting to be as simple as possible, could ZFS be
configured so that this property is set on creation by default?

That means that it''s something that just works for the average user,
more advanced users can create pools that don''t auto snapshot, and
importing any existing pool preserves the current behaviour.

Ross
--
This message posted from opensolaris.org

Chris Gerhard wrote:
>> I''m not sure there''s an easy way to please everyone
to be honest :-/
> 
> I''m not sure you are right there. If there was an SMF property
that you
> set to set the default behaviour and then you set it to true on 
> something that looked like a laptop and false otherwise. Or you could 
> just turn it on by default for root pools. Indeed the installation could 
> set the property.
It''s going to be turtles all the way down isn''t it?

That is, we''d now have a property to set whether or not the system sets
properties... Should we have another property set to tell the system 
whether to look at that property as well? :-)

I can see what you''re asking for, but it just seems a bit redundant, 
when all you have to do is set a property on the pools you don''t want 
auto-snapshotted, or just disable the service altogether.

I''ve got a suggested fix attached - but we''d need to
coordinate with the
desktop & install people to work out how they''re actually going to
set
the service property at install time to true.  Can you file an rfe 
against solaris/zfs/utility with me as RE if you still think this is 
important, but read on...

If we have such a setting, auto-include, set to false by default, then 
on a brand new system, doing

# svcadm enable auto-snapshot:frequent

would have no effect whatsoever - other than running a cron job that 
does nothing every 15 minutes. This strikes me as weird.
> While on  a desktop being on by default has some value on a server that 
> has been upgraded and therefore would have a backup strategy already in 
> place it does not.
In nv_100, SXCE has this off by default - the auto-snapshot SMF service 
already defaults to disabled, unfortunately time-slider had a 
postinstall script that enabled the services again. They''ve got that 
fixed in nv_102 I believe. So perhaps the auto-include property isn''t 
needed after all.
> Do we supply a script to delete all the auto-snapshot snapshots? Is 
> there anyway to recognise them apart from by their name?
Nope. The time-slider service just looks for snapshots of given names.

We could mark those snapshot with another zfs user property, but that''d
break backwards compatibility with earlier versions of Solaris that 
don''t have snapshot property support, so I''d rather not do
that if possible?

	cheers,
			tim
> 
>>
>> That said, how often do you import or create pools where this would be 
>> an issue?  If you''re importing pools you''ve used on
such a system
>> before, then you''d already have the property set on the root
dataset.
>>
>> If you''re constantly importing brand new pools, then yes,
you''ve got a
>> point.
> 
> You only have to have this mess with one pool which is being uses as the 
> target for a backup for the consequences to be horrible. For that reason 
> alone it needs to default to off.
> 
> Don''t get me wrong. The service is really nice and the gui
integration
> looks like it could be a thing of beauty if it can be made to scale. 
> Indeed on my daughter''s laptop it looks great. It''s just
it should
> default to being off with a really easy way to turn it on rather than 
> the other way round.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: auto-include.patch
URL:
<http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20081028/88d326ae/attachment.ksh>