Date: Fri, 9 Feb 1996 20:30:41 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: coredump@onyx.nervosa.com (invalid opcode) Cc: current@FreeBSD.org Subject: Re: How Message-ID: <199602100330.UAA13444@phaeton.artisoft.com> In-Reply-To: <Pine.BSF.3.91.960209165454.898B-100000@onyx.nervosa.com> from "invalid opcode" at Feb 9, 96 04:55:52 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> Just how dangerous is it to mount disks with async? If your machine > somehow crashes, do you rick losing all your data? Of course, you risk > that with sync also... IMO, very dangerous. The fsck utility (see the paper in the source tree) *depends* on the ordering of operations. The async option allows the cluster code to reorder writes, since it does not insist on the write to disk taking place before the call returns. This potentially allows you to queue a large number of order-dependent operations, and have some of them committed out of sequence at the time of the crash. If you have a UPS and are relatively confident of the stability of the platform, then it is possible for it to be less dangerous (but still more dangerous than doing sync writes). The main point of the sync operations is to cause the FS operations which modify the file system structure itself to be idempotent (see the VIVAFS paper for an analysis of what is or isn't an operation that can be async); in other words, meta-data. Using sync operations, you can only lose the last meta-data operation that occured before the crash, and then only in rare cases of the write to disk being unable to complete on the remaining energy in the system. The general result is that directory entries for files created before the last "sync" by the "update" process will end up in lost+found (but only the name information will be lost) if the power fails. To allow your system to *always* be recoverable (even if data writes to open files may be lost), you should mount sync. To guard against data loss is an application-specific problem. There is O_WRITESYNC to cause data writes to be synchronus, and there are various techniques, such as journalling, logging, and transaction tracking (multi stage commit, etc.) that should be implemented in the application. For anything other than initial install, copying, archiving, async is a bad bet. For those particular operations, it's a big win. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199602100330.UAA13444>