Is there anyway to fssnap the root file system?  I would like to use a
snapshot for backup, but when I try to do that I get the error:
snapshot error: File system could not be write locked

A little more info.  Up until the end of last week, the system disk
was partitioned into seperate /, /var, /usr, /opt & /export partitions.
For backup I would fssnap the /var, /export & /opt partitions.  /var
because of the various log files that might be changing.  /export
because we have some old diskless workstations with their roots on
/export/root.  /opt just because I could.  Late last week I had to
replace the disk as the old one was going bad.  On the new disk I
just put everything into one large file system.  I assumed that I
could mount / with logging with no problems and I never even thought
that there could be a problem with taking a snap shot.

If I can't take a snap shot, I expect that I may redo the disk with
seperate partitions, at least seperate /var and /export.
-- 
Tom Schulz
schulz@adi.com

I should add that we are running Solaris 8.  I expect to upgrade to
Solaris 10 in a couple of months.

In article <dj3jpm$2ki$1@bluegill.adi.com>,
Thomas Schulz <schulz@adi.com> wrote:
>Is there anyway to fssnap the root file system?  I would like to use a
>snapshot for backup, but when I try to do that I get the error:
>snapshot error: File system could not be write locked
>
>A little more info.  Up until the end of last week, the system disk
>was partitioned into seperate /, /var, /usr, /opt & /export partitions.
>For backup I would fssnap the /var, /export & /opt partitions.  /var
>because of the various log files that might be changing.  /export
>because we have some old diskless workstations with their roots on
>/export/root.  /opt just because I could.  Late last week I had to
>replace the disk as the old one was going bad.  On the new disk I
>just put everything into one large file system.  I assumed that I
>could mount / with logging with no problems and I never even thought
>that there could be a problem with taking a snap shot.
>
>If I can't take a snap shot, I expect that I may redo the disk with
>seperate partitions, at least seperate /var and /export.
>-- 
-- 
Tom Schulz
schulz@adi.com

Thomas Schulz <schulz@adi.com> wrote:
> Is there anyway to fssnap the root file system?  I would like to use a
> snapshot for backup, but when I try to do that I get the error:
> snapshot error: File system could not be write locked

Are you running ntp/xntp?  By default that program runs in the realtime
processing class, and has a current directory in the root filesystem.
You can't write lock the filesystem while that's true.

-- 
Darren Dunham                                           ddunham@taos.com
Senior Technical Consultant         TAOS            http://www.taos.com/
Got some Dr Pepper?                           San Francisco, CA bay area
         < This line left intentionally blank to confuse you. >

In article <dj3jpm$2ki$1@bluegill.adi.com>,
	schulz@adi.com (Thomas Schulz) writes:
> Is there anyway to fssnap the root file system?  I would like to use a
> snapshot for backup, but when I try to do that I get the error:
> snapshot error: File system could not be write locked

You might find that killing off xntpd allows it to be write locked.

-- 
Andrew Gabriel

In article <hwc5f.17306$6e1.7641@newssvr14.news.prodigy.com>,
Darren Dunham  <ddunham@redwood.taos.com> wrote:
>Thomas Schulz <schulz@adi.com> wrote:
>> Is there anyway to fssnap the root file system?  I would like to use a
>> snapshot for backup, but when I try to do that I get the error:
>> snapshot error: File system could not be write locked
>
>Are you running ntp/xntp?  By default that program runs in the realtime
>processing class, and has a current directory in the root filesystem.
>You can't write lock the filesystem while that's true.

Yes, we are running ntp.  I will try killing that and see what happens.
I am thinking that it might be better to repartition the disk rather than
to take ntp down and up for every backup.

>
>-- 
>Darren Dunham                                           ddunham@taos.com
>Senior Technical Consultant         TAOS            http://www.taos.com/
>Got some Dr Pepper?                           San Francisco, CA bay area
>         < This line left intentionally blank to confuse you. >


-- 
Tom Schulz
schulz@adi.com

schulz@adi.com (Thomas Schulz) writes:

> Yes, we are running ntp.  I will try killing that and see what happens.
> I am thinking that it might be better to repartition the disk rather than
> to take ntp down and up for every backup.

Why? Simply create a script that stops xntpd, creates a snapshot, starts
xntpd and perform backup. No need to repartition.

Bye, Dragan

-- 
Dragan Cvetkovic, 

To be or not to be is true. G. Boole      No it isn't.  L. E. J. Brouwer

!!! Sender/From address is bogus. Use reply-to one !!!

Dragan Cvetkovic <me@privacy.net> wrote:
> schulz@adi.com (Thomas Schulz) writes:

>> Yes, we are running ntp.  I will try killing that and see what happens.
>> I am thinking that it might be better to repartition the disk rather than
>> to take ntp down and up for every backup.

> Why? Simply create a script that stops xntpd, creates a snapshot, starts
> xntpd and perform backup. No need to repartition.

But that's not kind to ntp, which wants to keep running to remain
stable.

The only problem here is that it's working directory is in root.  I see
two possible workarounds.

#1 Have it run in a non-RT class.  You can use priocntl for that.  I
   don't think it'll have a dramatic effect on the timekeeping, but you
   might not want to do this if you need very accurate time on this
   machine.

$ pgrep ntp
302
$ /usr/bin/ps -o class,pid -p 302
 CLS   PID
  RT   302
$ priocntl -s -c TS 302
$ /usr/bin/ps -o class,pid -p 302
 CLS   PID
  TS   302

Thus taking it from the realtime class to the timesharing class.  (I
suppose I should have tried a fssnap at that point, but didn't...)

#2 Run it with the working directory not in root.  I don't see any
   reason it couldn't run in /tmp or /var/run, unless you wanted to
   retain any core files that might be generated.  I'm not certain how
   best to achieve that, but I saw a post that suggested someone had
   good luck using chroot.

-- 
Darren Dunham                                           ddunham@taos.com
Senior Technical Consultant         TAOS            http://www.taos.com/
Got some Dr Pepper?                           San Francisco, CA bay area
         < This line left intentionally blank to confuse you. >

In article <FXf5f.2560$D13.1263@newssvr11.news.prodigy.com>,
Darren Dunham  <ddunham@redwood.taos.com> wrote:
>Dragan Cvetkovic <me@privacy.net> wrote:
>> schulz@adi.com (Thomas Schulz) writes:
>
>>> Yes, we are running ntp.  I will try killing that and see what happens.
>>> I am thinking that it might be better to repartition the disk rather than
>>> to take ntp down and up for every backup.


It is ntpd.  Stopping it does allow me to do a snapshot.

>> Why? Simply create a script that stops xntpd, creates a snapshot, starts
>> xntpd and perform backup. No need to repartition.
>
>But that's not kind to ntp, which wants to keep running to remain
>stable.


That is what I was thinking, but perhaps stopping and starting it in the
middle of the night would not be too bad.

>The only problem here is that it's working directory is in root.  I see
>two possible workarounds.
>
>#1 Have it run in a non-RT class.  You can use priocntl for that.  I
>   don't think it'll have a dramatic effect on the timekeeping, but you
>   might not want to do this if you need very accurate time on this
>   machine.
>
>$ pgrep ntp
>302
>$ /usr/bin/ps -o class,pid -p 302
> CLS   PID
>  RT   302
>$ priocntl -s -c TS 302
>$ /usr/bin/ps -o class,pid -p 302
> CLS   PID
>  TS   302
>
>Thus taking it from the realtime class to the timesharing class.  (I
>suppose I should have tried a fssnap at that point, but didn't...)


I find it already running in the TS class.  I am running the ntpd from
ntp.org, not the one supplied by sun, if that makes a difference.
Oh well...

>#2 Run it with the working directory not in root.  I don't see any
>   reason it couldn't run in /tmp or /var/run, unless you wanted to
>   retain any core files that might be generated.  I'm not certain how
>   best to achieve that, but I saw a post that suggested someone had
>   good luck using chroot.


Thanks for the ideas and information.  I will have to think about the best
thing to do, but at least I can make it work now.

>-- 
>Darren Dunham                                           ddunham@taos.com
>Senior Technical Consultant         TAOS            http://www.taos.com/
>Got some Dr Pepper?                           San Francisco, CA bay area
>         < This line left intentionally blank to confuse you. >
-- 
Tom Schulz
schulz@adi.com