> > Prompted by a recent /. article on atime vs realtime ranting by some > > Linux kernel hackers (Linus included) I went back and looked at the > > mount_ufs(1M) man page because I was sure that OpenSolaris had more than > > just atime,noatime. Yep sure enough UFS has dfratime. > > > > So that got me wondering does ZFS need dfratime or is it just not a > > problem because ZFS works in a different way. > > I believe ZFS will delay atime updates waiting for more writes to come > in, but it will eventually write them anyway (5 seconds?). dfratime > postpones the write until another write comes in, so it seems legitimate > to me for ZFS to have such an option.
But a traditional filesystem isn't going to write anything without a request. ZFS is constantly updating the pool/uberblock status the way things currently work. So even if you choose to defer the atime update until much longer, it won't prevent writes from being scheduled anyway. > > If ZFS did have dfratime > > how would it impact the "always consistent on disk" requirement. One > > though was that the ZIL would need to be used to ensure that the writes > > got to disk eventually, but then that would mean we were still writing > > just to the ZIL instead of the dataset itself. > > I don't think dfratime changes the disk consistency at all. Wouldn't > writing to the ZIL with dfratime on defeat the purpose? If we need to > write to the ZIL for some other write, though, then it would be ok to > flush the atime updates out too. > > All that said, I believe the primary use case for dfratime is laptops, > and therefore it shouldn't be a high priority for the ZFS team. I think I'd guess it to be most useful when atime updates are a significant fraction of scheduled writes, so that their removal or deferral makes a difference. I just don't think that'll be the case on ZFS at the moment. Of course gathering some actual numbers would be a good idea. -- 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
