Date: Wed, 6 Mar 2013 11:32:50 +0400 From: Lev Serebryakov <lev@FreeBSD.org> To: Don Lewis <truckman@FreeBSD.org> Cc: freebsd-fs@FreeBSD.org, ivoras@FreeBSD.org, freebsd-geom@FreeBSD.org Subject: Re: Unexpected SU+J inconsistency AGAIN -- please, don't shift topic to ZFS! Message-ID: <1644513757.20130306113250@serebryakov.spb.ru> In-Reply-To: <201303060715.r267FDHS015118@gw.catspoiler.org> References: <612776324.20130301152756@serebryakov.spb.ru> <201303060715.r267FDHS015118@gw.catspoiler.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Hello, Don. You wrote 6 =DC=D0=E0=E2=D0 2013 =D3., 11:15:13: DL> Did you have any power failures that took down the system sometime DL> before this panic occured? By default FreeBSD enables write caching on I had other panic due to my inaccurate hands... But I don't remeber any power failures, as I havee UPS and this one works (I check it every month). DL> That means that the drive will immediately acknowledge writes and is DL> free to reorder them as it pleases. DL> When UFS+SU allocates a new inode, it first clears the available bit in DL> the bitmap and writes the bitmap block to disk before it writes the new DL> inode contents to disk. When a file is deleted, the inode is zeroed on DL> disk before the available bit is set in the bitmap and the bitmap block DL> is written. That means that if an inode is marked as available in the DL> bitmap, then it should be zero. The system panic that you experienced DL> happened when the system was attempting to allocate an inode for a new DL> file and when it peeked at an inode that was marked as available, it DL> found that the inode was non-zero. DL> What might have happened is that sometime in the past, the system was in >[SKIPPED] DL> tried to allocate the inode in question. This scenario looks plausible, but it raises another question: does barriers will protect against it? It doesn't look so, as now barrier write is issued only when new inode BLOCK is allocated. And it leads us to my other question: why did not mark such vital writes with flag, which will force driver to mark them as "uncacheable" (And same for fsync()-inducted writes). Again, not BIO_FLUSH, which should flush whole cache, but flag for BIO. I was told my mav@ (ahci driver author) that ATA has such capability. And I'm sure, that SCSI/SAS drives should have one too. --=20 // Black Lion AKA Lev Serebryakov <lev@FreeBSD.org>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1644513757.20130306113250>