On Tue, Jan 28, 2014 at 4:55 AM, Philip Guenther <guent...@gmail.com> wrote: > On Tue, Jan 28, 2014 at 12:27 AM, Andres Perera <andre...@zoho.com> wrote: >> On Sun, Jan 26, 2014 at 5:07 PM, Philip Guenther <guent...@gmail.com> wrote: >>> On Sun, Jan 26, 2014 at 11:40 AM, emigrant <emig...@gmail.com> wrote: >>>> My Master machine is dead, exactly HDD(thank you God for CARP+pfsync) :). >>>> >>>> root@master[/etc]wd0(pciide0:0:0): timeout >>>> type: ata >>>> c_bcount: 16384 >>>> c_skip: 0 >>> ... >>>> /: got error 5 while accessing filesystem >>>> panic: softdep_deallocate_dependencies: unrecovered I/O error >>>> Stopped at Debugger+0x4: popl %ebp >>>> RUN AT LEAST 'trace' AND 'ps' AND INCLUDE OUTPUT WHEN REPORTING THIS PANIC! >>>> DO NOT EVEN BOTHER REPORTING THIS WITHOUT INCLUDING THAT INFORMATION! >>>> ddb> >>> >>> This is a fundamental problem of softdeps:it can delay an operation to >>> a point where other operations depend on it in a such a way that if >>> the I/O for that first operation fails, the dependent operations >>> cannot be undone and the failure propagated up safely. Rather than >>> live a lie, it'll panic the system and die. >> >> the way the decision to panic() was stated implies that the course of >> action is justified, when detaching the disk/hub, or forcefully >> mounting it read only, are alternatives that could be explored. > > How do those alternative actions, which can only fail in-progress and > future operation, satisfactorily resolve the case of operations WHICH > HAVE ALREADY RETURNED SUCCESS but whose effects will actually be lost > and not durable? > > I'm no expert on softdeps, so maybe you have a better explanation for > why Kirk made the choice he did to have it panic in some cases?
well, i'm no expert either. now that we have presented our credentials, let's go back to what was already conjecture do you understand that disks have write caches that don't give a hoot about posix mkdir() rename() and so on? can bit rot change a inode type from directory to file, and vice versa? do you want the kernel to figure these out after the fact and retroactively panic() for each occurence, neatly queueing them boot after boot or do you want to grow a pair of balls instead? > > > Philip Guenther
