Hi Note that the plugin:zfs-send instance was put into maintenance at the request of time-slider:default - ie it used something likens cadmium mark.
Looking at the start method for time-slider (vs prop -p start/exec time-slider) function check_failure performs svcadm mark maintenance for failed commands. The only use of check_failure on my s12 system is after frontal edit, but yours may vary. Worst case I would add some strategic set -x to the start method script and then have a look at the svc log file after failure to see where it goes wrong. Also worth knowing that time-slider has a "feature" whereby it only manages leaf datasets, ie those with no child datasets. A real pest. Likely easy to fix, but it is not seen as an enterprise feature nowadays, I think. Gavin On Thursday, 21 November 2013, Chris Wells wrote: > OK, I've now completely disabled timeslider, deleted all snapshots, > deleted all BEs, other than the default, reneabled timeslider, cleared > any svc issue, and ensured that snapshots are enabled: > > # zfs set -r snapdir=visible rpool > # zfs set -r com.sun:auto-snapshot=true rpool > # zfs set com.sun:auto-snapshot=false rpool/swap > # zfs set com.sun:auto-snapshot=false rpool/dump > > SO - > > 1) svcs -x still shows svc in maintenance mode: > > # svcs -x > svc:/application/time-slider/plugin:zfs-send (Time Slider Plugin Framework) > State: maintenance since November 21, 2013 01:18:21 AM EST > Reason: Maintenance requested by "svc:/application/time-slider:default" > See: /var/svc/log/application-time-slider:default.log > See: http://support.oracle.com/msg/SMF-8000-R4 > See: /var/svc/log/application-time-slider-plugin:zfs-send.log > Impact: This service is not running. > > > 2) snapshots are missing for / (rpool/ROOT/SRU11.1.12.5.0) : > > # df -k / > Filesystem 1K-blocks Used Available Use% Mounted on > rpool/ROOT/SRU11.1.12.5.0 > 398118676 4909286 393209390 2% / > # df -k /.zfs > Filesystem 1K-blocks Used Available Use% Mounted on > rpool/ROOT/SRU11.1.12.5.0 > 398118737 4909286 393209451 2% / > # ls /.zfs > shares snapshot > # ls /.zfs/snapshot > # > > > Any ideas? Anyone? > > ---------- Forwarded message ---------- > From: Chris Wells <[email protected] <javascript:;>> > Date: Tue, Nov 12, 2013 at 8:35 AM > Subject: Solaris 11.1 Timeslider > To: [email protected] <javascript:;> > > > Hi guys. > > I've been having a problem with Timeslider (well, since about > OpenSolaris Nevada 130 something). > Having done a complete reinstall of Solaris 11.1, and brought it up to > the current SRU (SRU11.1.12.5.0), I'm still having issues. > > What I'm finding is that timeslider fills up past the autodelete level > (75%), and generally gets bogged down, and fills up to 100% eventually > without corrective action. > > And the svc:/application/time-slider/plugin:zfs-send service (Time > Slider Plugin Framework), usually gets put into maintenance mode by > time-slider. > > What I've found is that time-slider puts zfs holds (why?) on zfs > snapshots, and the snapshots never get deleted. > > I can unblock it with something like: > > fixtimeslider.sh : > ------------------------ > #!/bin/sh > > svcadm disable -t time-slider > > for f in `zfs list -H -t snapshot -o name`; do \ > zfs release -r org.opensolaris:time-slider-plugin:zfs-send $f; > done > > svcadm clear svc:/application/time-slider/plugin:zfs-send > > svcadm enable time-slider > ------------------------ > > I ran this over the weekend, and was able to reduce the zpool > utilisation down from 95% used down to 60%. However, zfs held > snapshots have started appearing again: > > root@marvin:~# for f in `zfs list -t snapshot -o name`; do zfs holds > $f; done 2>&1 | grep "zfs-send" > rpool@zfs-auto-snap_hourly-2013-11-11-00h46 > org.opensolaris:time-slider-plugin:zfs-send Mon Nov 11 00:46:50 2013 > rpool/ROOT/SRU11.1.11.4.0/var@zfs-auto-snap_hourly-2013-11-11-00h46 > org.opensolaris:time-slider-plugin:zfs-send Mon Nov 11 00:46:49 2013 > rpool/ROOT/SRU11.1.12.5.0/var@zfs-auto-snap_hourly-2013-11-11-00h46 > org.opensolaris:time-slider-plugin:zfs-send Mon Nov 11 00:46:50 2013 > rpool/ROOT/s11.1ga/var@zfs-auto-snap_hourly-2013-11-11-00h46 > org.opensolaris:time-slider-plugin:zfs-send Mon Nov 11 00:46:48 2013 > rpool/VARSHARE@zfs-auto-snap_hourly-2013-11-11-00h46 > org.opensolaris:time-slider-plugin:zfs-send Mon Nov 11 00:46:49 2013 > rpool/VMs@zfs-auto-snap_hourly-2013-11-11-00h46 > org.opensolaris:time-slider-plugin:zfs-send Mon Nov 11 00:46:49 2013 > rpool/download@zfs-auto-snap_hourly-2013-11-11-00h46 > org.opensolaris:time-slider-plugin:zfs-send Mon Nov 11 00:46:47 2013 > rpool/export/home/crispi@zfs-auto-snap_hourly-2013-11-11-00h46 > org.opensolaris:time-slider-plugin:zfs-send Mon Nov 11 00:46:47 2013 > rpool/export/users@zfs-auto-snap_hourly-2013-11-11-00h46 > org.opensolaris:time-slider-plugin:zfs-send Mon Nov 11 00:46:48 2013 > rpool/ftp@zfs-auto-snap_hourly-2013-11-11-00h46 > org.opensolaris:time-slider-plugin:zfs-send Mon Nov 11 00:46:46 2013 > rpool/incoming@zfs-auto-snap_hourly-2013-11-11-00h46 > org.opensolaris:time-slider-plugin:zfs-send Mon Nov 11 00:46:46 2013 > rpool/isos@zfs-auto-snap_hourly-2013-11-11-00h46 > org.opensolaris:time-slider-plugin:zfs-send Mon Nov 11 00:46:47 2013 > rpool/squid@zfs-auto-snap_hourly-2013-11-11-00h46 > org.opensolaris:time-slider-plugin:zfs-send Mon Nov 11 00:46:45 2013 > rpool/www@zfs-auto-snap_hourly-2013-11-11-00h46 > org.opensolaris:time-slider-plugin:zfs-send Mon Nov 11 00:46:45 2013 > > > So - Why is this happening? And what is the long term fix? - surely > zfs/timeslider should be more reliable than this? > > > -- > Regards, > > Chris > > > -- > Regards, > > Chris > > _______________________________________________ > msosug mailing list > [email protected] <javascript:;> > http://mexico.purplecow.org/m/listinfo/msosug >
_______________________________________________ msosug mailing list [email protected] http://mexico.purplecow.org/m/listinfo/msosug
