Date: Mon, 17 Apr 2000 12:34:49 -0700 (PDT) From: Scott Hess <scott@avantgo.com> To: Alfred Perlstein <bright@wintelcom.net> Cc: Rahul Siddharthan <rsidd@physics.iisc.ernet.in>, Rasmus Skaarup <rasmus@gal.dk>, freebsd-questions@FreeBSD.ORG Subject: Re: disc io - sync and async Message-ID: <Pine.LNX.4.21.0004171233410.2992-100000@river.avantgo.com>
next in thread | raw e-mail | index | archive | help
[Sorry if you got a duplicate, I got a bounce due to mail server misconfiguration on my end. -scott] On Mon, Apr 17, 2000 at 08:45:52AM -0700, Alfred Perlstein wrote: > Let's take the worst case scenario and assume that you just rebuilt > the password file database under Linux and at the same time a user > just created a somewhat large file: > > Now since meta-data isn't consistant under async it's quite possible > that the password file's inode hasn't been truncated to free it's > blocks while the user's file's inode has been given ownership of > the blocks on disk. > > *power goes out* > *machine comes back up* > *user suprised to find bits of your password file in his tempfile* > *administrator suprised to find instance of 'crack' running on > system* > > oh joy. > > Ok, considering that which do you think is a more reasonable default? Unfortunately, sync versus async doesn't address that issue. Even without an async mount, a file can be allocated blocks on the disk without having written to those blocks. Say the program writes 8k of data to a file with 8k of data. The kernel allocates a new block out of the free bitmap, and immediately writes the updated inode - but doesn't necessarily immediately write the new data block. If the system crashes at that point, and the newly-reserved block was part of the newly-freed /etc/passwd... I've actually been bitten by this. I had written a storage subsystem which, by virtue of carefully arranged rename calls, should have made file updates atomic (you either got the old file or the new file, but always a valid file). We once had a system crash, and after fsck had completed, a large number of the files were corrupt. The system had been running for months and terabytes of transfers, with zero detected corruption. Inspection indicated that corruption was data that should under no circumstances have existed in the files in question. The only explaination I could find was that the rename had been synced to disk before the data blocks were sync'ed. This is one of the things softupdates is supposed to fix. [Since I didn't trust softupdates at that time, I fixed my problem by explicitely fsync'ing the file before renaming it.] Later, scott 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.LNX.4.21.0004171233410.2992-100000>