Date: Tue, 5 Apr 2011 16:35:40 +0200 From: Borja Marcos <borjam@sarenet.es> To: Andriy Gapon <avg@FreeBSD.org> Cc: freebsd-scsi@FreeBSD.org Subject: Re: propose: change some sense codes handling Message-ID: <2DA9EF9F-F548-4C24-A237-7F5BADEF9A38@sarenet.es> In-Reply-To: <4D9B2531.4070202@FreeBSD.org> References: <4D9AF9B7.9030107@FreeBSD.org> <D10B0D62-E11E-445C-B9FA-DB4276F678B0@sarenet.es> <4D9B0DF7.8020104@FreeBSD.org> <4D0D7E78-2491-4D45-9DDE-58E360C6BA06@sarenet.es> <4D9B1A9E.4040007@FreeBSD.org> <ADD4B5D3-11C8-412A-A130-2BD03ECEEFAC@sarenet.es> <4D9B2531.4070202@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Apr 5, 2011, at 4:20 PM, Andriy Gapon wrote: >>> Sure. So, still why "Power on occurred" or "Device internal reset" = should be >>> SS_RDEF while "Power on, reset, or bus device reset occurred" should = be SS_FATAL? >>=20 >> Seems to be safer to treat it as fatal, don't you think? >=20 > Seems to be safe to treat everything as fatal, but less convenient = perhaps? > So let me clarify. Do you suggest that all "reset" and "power" = statuses be > treated as SS_FATAL? Or do you single-out "Power on, reset, or bus = device reset > occurred"? Sorry to write in such broad terms, but I'm not that familiar with the = source code of the SCSI subsystem. Hence the comments I'm writing are = "high-level" in nature :) Anyway I hope they will be useful.=20 ASC/ASCQ codes belonging to the 0x29 range received during an operation = different than an INQ done for a bus probe should be treated with care, = I think. In case they affected to a device storing mounted filesystems, = I think it should register as a fatal error. Ignoring it could lead to = data corruption if the power cycle has happened before data has been = committed to the disk (I'm talking about disks of course). Doing this can lead to "spurious" errors with flaky devices, and maybe = the operation would have succeeded. But, again, I think it's better to = reveal the error rather than hiding it and risking data corruption. = Moreover, if we make flaky devices work just right, we are favouring bad = manufacturers. I remember a similar discussion on BUGTRAQ several years = ago regarding a "MIME-polish program". My posture was that broken MIME = should go to the trash period. Regards ;) Borja.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2DA9EF9F-F548-4C24-A237-7F5BADEF9A38>