Date: Fri, 16 Jun 2006 11:18:03 -0400 From: "Bob Johnson" <fbsdlists@gmail.com> To: "=?ISO-8859-1?Q?Pablo_Mar=EDn_Ram=F3n?=" <pabmara@fiv.upv.es> Cc: freebsd-questions@freebsd.org Subject: Re: FFS data integrity Message-ID: <54db43990606160818u1e3df3b8sfb30066fc005661f@mail.gmail.com> In-Reply-To: <20060616104704.GA11222@localhost> References: <20060616104704.GA11222@localhost>
next in thread | previous in thread | raw e-mail | index | archive | help
On 6/16/06, Pablo Mar=EDn Ram=F3n <pabmara@fiv.upv.es> wrote: > Here goes a newbie question about classical FFS (without > softupdates). > > As metadata is updated synchronously, can an i-node, at some > point, end pointing to not written yet data blocks? Is this a > security risk, i.e., can those pointed to data blocks pertain to > another user's deleted on memory but not deleted on disk data, or > that deleted data will be marked in metadata as not initialized > and after a crash fsck will fix all i-nodes pointing to it? > The short answer is that fsck can detect the bad inodes and fix or delete them. Assuming no programming errors, you don't have to worry about a file containing bogus data after fsck has run. Unfortunately, if write-caching is enabled on your hard drive (and it probably is, for speed), then the drive may internally re-order the writes and the carefully crafted sequence of writes disappears, so there are no guarantees (or at least, not as many). Whether this is actually a problem depends on the brand, model, and firmware version of the drive, because some drives claim that data has been written to the disk when it is actually only in the drive buffer, while other drives are more honest. More details are found in http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/configtuning-disk= .html > AFAIK, softupdates and ext3 in the default mode (data=3Dordered) > don't have this problem, but journalling filesystems that journal > only metadata do. Is this correct? I think that is answered in the handbook section referenced above. - Bob
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?54db43990606160818u1e3df3b8sfb30066fc005661f>