> >> Does that mean that paging out dirty mmap pages go to new places and > >> require metadata updates as well? > >> > > Yes. > Indeed, given that ZFS always writes new places (except for uberblock as > you noted), then that does make the snapshots easier and accounts for > there being no explicit code to "set COW on disk blocks", or such. > > From a ufs/vxfs background, the thought of allocating additional disk > storage to page out to a memory mapped file or of changing metadata to > point to new blocks and hence needing to write out metadata as part of > paging out modified file data seems foreign to me. If the metadata > writes can be bundled into the same transaction, perhaps there's no more > serialization latency on a pageout... ?
That's not something that I've tested at all. Perhaps you could investigate? > Is this also another case where > one might get ENOSPC when one doesn't on other filesystems (paging out > to an existing MMF in a full ZFS pool)? That depends on how you're using snapshots. Traditionally, they are a way of overcommiting disk space to multiple uses in the hope that everything fits. Note that because of the snapshot guarantee, it is the one that wins in a conflict, not the live filesystem. If you need to avoid that, you can use quotas and make sure that your snapshots plus actual filesystem space does not exceed the pool capacity. Then you are not overcommitted, and space should be available for writes. Or you can just monitor everything very closely so that you're never near the edge. > From the comments in the source tour about the ZIL, I did note the > statement that file contents do not go through the ZIL unless needed for > O_DSYNC or fsynch() semantics, so I wasn't sure how else they might be > different. > >> How do snapshots interact with open files or files with pages in the > >> OpenSolaris page cache? > >> > > > > I don't believe they do. Are you thinking of something in particular? > > > I am generally interested in understanding file consistency and cache > coherency. I'd like to know what exactly is being snapshotted and what > is consistent within a snapshot. > > I subsequently saw an earlier thread on "ZFS consistency guarantee" > (http://www.opensolaris.org/jive/thread.jspa;?messageID=124809) where > you and others pointed out that application state is not consistent at a > snapshot unless the application has been quiesced or otherwise brought > to a consistent state. Even then, I'm curious about the interaction > with the OpenSolaris page cache... > > As is generally known and is explained well by Roch Bourbonnais in > http://blogs.sun.com/roch/entry/nfs_and_zfs_a_fine, NFS places an extra > requirement for committing writes to stable storage upon file close. > For local filesystems, a close() will complete without all modified file > data being written to disk yet. Does all such file data get into a > snapshot, or only data that has happened to be pushed out to disk by the > time of the snapshot? (e.g. local open(), write(), close(), snapshot). I have no knowlege of what the code in that area does. My assumption has been that the equivalent of an fsync() is done prior to the snapshot. Someone else will have to comment. -- Darren Dunham [EMAIL PROTECTED] 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. > _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
