Date: Fri, 10 Jan 1997 09:20:12 -0600 (CST) From: Karl Denninger <karl@Mcs.Net> To: scrappy@hub.org (The Hermit Hacker) Cc: hackers@freebsd.org Subject: Re: mount -o async on a news servre Message-ID: <199701101520.JAA20582@Jupiter.Mcs.Net> In-Reply-To: <Pine.BSF.3.95.970110065253.5112P-100000@thelab.hub.org> from "The Hermit Hacker" at Jan 10, 97 06:59:08 am
next in thread | previous in thread | raw e-mail | index | archive | help
> Hiya... > > Exactly *how* dangerous is setting a file system to async? Quite. > In my case, I'm braving it on a news server, just the ccd > device that contains both the news admin and spool directories. The > drive is local to the system. > > My understanding of asynchronous I/O is that it doesn't wait > for an acknowledgement from the system before going to the next > write (only, its a very basic understanding?), so I'm curiuos as how > it would handle writting the history file itself? If you crash the superblock and its backup copies may not be properly written. If this is corrupted in the wrong sorts of ways, your root inode can end up unallocated -- the consequence of this is that the entire filesystem is destroyed. fsck is designed to fix filesystem inconsistencies. Running async increases the severity of those inconsistencies. If you have the update(1) job disabled as well, the superblock could be *hours* out of date. For this reason disabling update(1) makes this trick even more dangerous. Basically, when you write or create a file the superblock has to be updated along with the on-disk copy of the inodes involved. If you turn on async you're allowing these writes (which are normally synchronous with the create or open call) to be asynchronous -- that is, done later. The problem is that if/when you crash they might not have been done at all! The consequence is that the file(s) in question may be lost. Since DIRECTORY creates and updates are just file operations at the kernel level, this can also apply to *directories*. If it hits the root directory of the disk volume you're badly screwed (instead of slightly screwed :-). This information is known as the filesystem "metadata" (its not the actual file data, but the indices which allow you to get to the data itself). > The only risk that I can see is that if the system crashes, > I'll have (might have) a corrupted file system, but is that my only > risk? ie. if I turned on async for a period of time (long enough for > a backlog from one system to catch up?) and then turned it back off > again, would that be reasonably safe? Yes. > BTW...what exactly does fastfs do? My understanding is that > this is basically what it does, turns the file system to be async vs > sync... I believe so, yes. -- -- Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service | 99 Analog numbers, 77 ISDN, Web servers $75/mo Voice: [+1 312 803-MCS1 x219]| Email to "info@mcs.net" WWW: http://www.mcs.net/ Fax: [+1 312 248-9865] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199701101520.JAA20582>