iirc, we would notify the user community that the FS'es were going to hang briefly.
Locking the FS'es is the best way to quiesce it, when users are worldwide, imo. Mark On Jan 31, 2011, at 9:45 AM, Torrey McMahon wrote: > A matter of seconds is a long time for a running Oracle database. The point > is that if you have to keep writing to a UFS filesystem - "when the file > system also needs to accommodate writes" - you're still out of luck. If you > can quiesce the apps, great, but if you can't then you're still stuck. In > other words, fssnap_ufs doesn't solve the quiesce problem. > > On 1/31/2011 10:24 AM, Mark Sandrock wrote: >> Why do you say fssnap has the same problem? >> >> If it write locks the file system, it is only for a matter of seconds, as I >> recall. >> >> Years ago, I used it on a daily basis to do ufsdumps of large fs'es. >> >> Mark >> >> On Jan 30, 2011, at 5:41 PM, Torrey McMahon wrote: >> >>> On 1/30/2011 5:26 PM, Joerg Schilling wrote: >>>> Richard Elling<richard.ell...@gmail.com> wrote: >>>> >>>>> ufsdump is the problem, not ufsrestore. If you ufsdump an active >>>>> file system, there is no guarantee you can ufsrestore it. The only way >>>>> to guarantee this is to keep the file system quiesced during the entire >>>>> ufsdump. Needless to say, this renders ufsdump useless for backup >>>>> when the file system also needs to accommodate writes. >>>> This is why there is a ufs snapshot utility. >>> You'll have the same problem. fssnap_ufs(1M) write locks the file system >>> when you run the lock command. See the notes section of the man page. >>> >>> http://download.oracle.com/docs/cd/E19253-01/816-5166/6mbb1kq1p/index.html#Notes _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
