OnlineJFS "freeze" command?

[Adam Garsha]

Tru64 AdvFS has a freezefs command to flush filesystem metadata (e.g. prior to a SAN level snap); AIX also has something similar. Does HP-UX OnlineJFS or LVM have a similar command or process?

[Jeff Schussele]

Hi Adam,

Yes it's the sync commmand.
Generally you'll want to issue several before a command like /etc/reboot which avoida all the "normal" shutdown sequences.

HTH,
Jeff

[Adam Garsha]

No thats not it. Tru64 AdvFS and AIX JFS/JFS2 also have a sync command. The "freeze-like" command that I am looking for not only flushes meta-data but also holds/blocks further changes (such that there is no possibility for filesystem meta-data changes during your SAN snap).

Here is what I am looking to automate:

1.) Freeze/Flush/Quiesce the database
2.) Freeze the multi-volume volume group or filesystem
3.) Take my snapshots of the Vdisks in the EVA using sssu
4.) Thaw the filesystem or volume group
5.) Thaw the database

Sync will flush buffers, but it is async and will only improve the odds that I don't get filesystem metadata corruption, it won't guarantee that I don't have it.

[A. Clay Stephenson · Accepted solution]

There is no command however in /usr/include/sys/fs/vx_ioctl.h the defines for VX_FREEZE and VX_THAW are there so it should be possible to create a command using an ioctl() call using a file descriptor opened on the filesystem's root inode. The supported method in HP-UX would be to do a vxfs snapof= mount; the vxfs snapshot takes only seconds.

[Duncan Edmonstone]

Adam,

what sort of database are you talking about? There's never been such a command on HPUX, because there's never really been a need - with intent logging filesystems, all metadata changes can be replayed with a very quick fsck on the backup host with no problem - certainly when I've done split mirror/business copy based Oracle backups there's never been a need to freeze the filesystem before doing the split - just a quick fsck before mounting the split.

HTH

Duncan

[Duncan Edmonstone]

... and I'd add that I've done *lots* of these and *never* had a problem with metadata changes.

Maybe IBM JFS/AdvFS intent logging functions aren't as reliable as VxFS?

(and that me just trying to push your buttons now!)

Duncan

[Duncan Edmonstone]

OK, now I'm done trolling, if you really want this functionality and can't be bothered to write your own freeze/thaw bit of C code, you could always have a look at this little excerpt from NetApp here:

http://www.ntap.com/tech_library/3308.html?fmt=print

This seems to do what you require... just ignore the NetApp specific stuff.

HTH

Duncan

[Adam Garsha]

Doesn't push my buttons, I hate IBM/AIX (and there support is probably the worst of any enterprise UNIX vendor that I've worked with).

If the HP supported method of obtaining SAN level snapshots is:

1.) Quiesce DB
2.) sync, sync, sync (cross fingers)
3.) Grab snapshot (at sanlevel, not filesystem level)
4.) Thaw DB

Then I am ok with the lack thaw/freeze at the filesystem level.

I guess before we move on business copy license, I want to be sure the method is "HP supported" (because on a parallel track IBM had back-pedaled on a similar process even though it seemed to work almost always... after dollars were already spent). I'll chase it from support/sales for the HP nod, just don't want to get burned again.

[A. Clay Stephenson]

Okay, I spent about 10 minutes over lunch studying the VX_FREEZE and VX_THAW ioctl()'s and comparing them to the Tru64 methods. Tru64 has the freezefs() and thawfs() system calls and has a bit more powerful implementation. Under HP-UX, the thawing process must already have the file open.

Given the constraints, I chose to implement it like this:

vx -t 120 -c "mystuff.sh" /mointpoint

This will issue a VX_FREEZE with a timeout of 120 seconds. If the freeze succeeds, the command "mystuff.sh" is executed and then the filesystem is thawed. If the freeze/thaw operations are successfull, the status of the executed comand is returned otherwise the non-zero status of the freeze/thaw operation is returned.

Compile it like this:
cc vx.c -o vx

Invoke as vx -u for usage.

[Adam Garsha]

Wow, thanks.