We are having an odd problem with our backups, which vdump from
Advfs cloned filesets on a Digital Unix 3.2G system.
We've started seeing "out of space" errors during the backups
when there appears to be plenty of space available:
Mar 26 10:45:17 emerald vmunix: WARNING: advfs cannot copy-on-write data to a clone file.
Mar 26 10:45:17 emerald vmunix: WARNING: encountered the following error: ENO_MORE_BLKS (-1040)
Mar 26 10:45:17 emerald vmunix: WARNING: do not continue using the clone fileset.
Mar 26 10:45:17 emerald vmunix: WARNING: original file set: name = students2, id = 2f5bc34f.00061380.00000002.8001
Mar 26 10:45:17 emerald vmunix: WARNING: clone file set: name = students2_cl, id = 2f5bc34f.00061380.00000005.8ad7
This seems coincident with a class assignment that has students
running scripts that traverse the file system that is having
problems.
My question is this:
Will the act of just changing the access time of a file cause a
copy-on-write operation for the file? For it's metadata? For both?
And, if this is the case, is there a safe way for traverse the file
system without resetting the access date of the file?
Thanks in advance for any answers.
- Saul
--
Saul Tannenbaum, Manager, Academic Systems |"Every year, I get more and more
stannenb_at_emerald.tufts.edu | cynical, but somehow I just can't
Tufts University Computing and | keep up." - Lilly Tomlin
Communications Services |
Finger for PGP Public Key |http://www.tufts.edu/~stannenb
Received on Thu Mar 27 1997 - 00:48:37 NZST