Friday, October 21, 2005

snapshot error: File system could not be write locked

Thomas 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.
> 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.

0 Comments:

Post a Comment

<< Home