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 drfatime. So that got me wondering does ZFS need drfatime or is it just not a problem because ZFS works in a different way. If ZFS did have dratime 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. If this is already covered somewhere please point me to the docs since I couldn''t see it mentioned in anything I''ve read. -- Darren J Moffat
Quoth Darren J Moffat on Thu, Aug 09, 2007 at 10:32:02AM +0100:> 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.> 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. David
> > 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 ddunham at taos.com 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. >
Quoth Darren Dunham on Wed, Aug 15, 2007 at 12:50:33PM -0700:> 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.Why does ZFS update the uberblock when there are no writes? David
>Quoth Darren Dunham on Wed, Aug 15, 2007 at 12:50:33PM -0700: >> 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. > >Why does ZFS update the uberblock when there are no writes?It doesn''t. I have a ZFS filesystem on an IDE disk which has an idle timer set; when there''s no ZFS I/O there''s also no disk I/O and the disk spins down. Casper
> >Quoth Darren Dunham on Wed, Aug 15, 2007 at 12:50:33PM -0700: > >> 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. > > > >Why does ZFS update the uberblock when there are no writes? > > It doesn''t. I have a ZFS filesystem on an IDE disk which has an idle > timer set; when there''s no ZFS I/O there''s also no disk I/O and the > disk spins down.I''ve incorrectly understood the flush algorithm. So then delaying or deferring the writes should work as well. In fact, if those are the only writes, then you''ll defer an entire label write/head seek sequence, which would likely be heavier weight than a simple inode update (and give you a bigger win). -- Darren Dunham ddunham at taos.com 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. >