Date: Thu, 23 Sep 1999 01:00:28 -0700 (PDT) From: Alfred Perlstein <bright@wintelcom.net> To: Alexander Maret <maret@atrada.de> Cc: "'freebsd-questions@freebsd.org'" <freebsd-questions@FreeBSD.ORG> Subject: RE: softupdates: do I understand this correctly? Message-ID: <Pine.BSF.4.05.9909230049280.6368-100000@fw.wintelcom.net> In-Reply-To: <58A002A02C5ED311812E0050044517F00D23BA@erlangen01.axis.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 23 Sep 1999, Alexander Maret wrote: > Thank you for your answer, but now I have to bother you with > some more questions because you nearly completly destroyed my > view of the topic :)) > > > No, it's not block caching that softupdates helps with, it's metadata. > > metadata is directory structures, inode maps, and the freelist. > > > > Softupdates ensures that directory operations are performed in the > > proper order but asynchronously. > > > > If you were to delete a file with softupdates enabled, softupdates > > would make sure that these things happen in order: > > 1) directory entry is removed (and flushed to disk) > > 2) inode is scrubbed and returned to the cyl grp (and > > flushed to disk) > > 3) blocks allocated to the inode are moved to the freelist > > (and flushed to disk) > > > > (a reverse of this operation would happen for creation of a file) > > > > Now in 'normal mode' (different from 'sync' mode) this order > > is enforced > > because the directory operations are done in order and don't return to > > the calling process until complete. > > Ok, I understand that. This is the reason why normal mode is slow. > Softupdates improves that by writing many of this operations in one > go. This saves time because the mechanic part of the harddrive doesn't > have to do so much work. No, you still don't understand, it's ok, read below. > > > 'sync' mode is diffent, sync mode is like 'normal' mode however there > > is no write caching _at all_. > > > > 'async' mode would queue all three operations (for the file create) > > but not enforce an ordering on them, if enough directory ops are > > being done async and you crash, the filesystem will become something > > out of "this is your mind, this is your mind mounted async with a > > power failure' *splat* > > > > What's the different between softupdates and async mode then. Yes, > softupdates takes care of the dependencies and ordering and can > even do another operation while the data is still in cache. On writing > the data to disk then, some operations are undone , written and then > again redone. But why is it not a great problem if a softupdates > disk fails but an async one. Both methods store data in cache and if > there is a power loss this data will be gone. Softupdates stores the > ordering as well, but untill now I thought this is just a speed > improvement thing. What is it that makes softupdates safer then async > mode? If I loose my softupdates-cached data I will see after a reeboot > a system with old data that I might have already deleted. What's with > async mode - should this be the same for this mode? Async mode doesn't bother to keep the disk in a consistant state... consider this scenario: A filesystem that is mounted 'async' You have file 'foo', foo owns blocks 100, 101 and 102. You delete 'foo' and create 'baz' and write some data to it... Let's say the filesystem decideds to allocate blocks 100, 101 and 102 because they are now free in memory... Now let's say that everything for 'baz' gets written out before foo's directory entry and inode are scrubbed clean. (the inode and directory entry) *power outtage* on reboot both baz and foo will point to the same blocks... this is what's called an inconsistancy. softupdates prevents this from happening by making sure all writes to disk happen in an order that will leave the system consistant. blocks 100, 101 and 102 wouldn't be placed on the freelist until foo is actually _really_ gone off the disk. there are many other operations where ordering becomes important to keep the disk in a consistant state in the case of a crash. Softupdates does not garantee that data won't be lost, just that on restart the system won't be scrambled. -- > I hope I don't bore you too much with my questions. Not at all, but you are asking some serious questions that deserve some research, if you don't already own it, you should look into purchasing: "The design and implementation of the 4.4 BSD operating system" By Mckusick It explains a lot of these types if OS internal issues. hope this answers your questions, -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.05.9909230049280.6368-100000>