> -----Original Message----- > From: David Lethe [mailto:[EMAIL PROTECTED] > Sent: Wednesday, April 16, 2008 1:39 AM > To: [EMAIL PROTECTED] > Cc: [email protected] > Subject: RE: [storage-discuss] Repairing known bad disk blocks before zfs > encounters them > > Let me clarify a few things. > > I already know where the bad blocks are ... zfs doesn't know. I want to > kindly instruct zfs to fix a problem. > Reasons for doing so .. > > 1) Remapping a bad sector can take well over 5 seconds on some disk > drives, sometimes much longer if there is a chunk of > Sequential bad blocks. Ever watch movies in hotels that just pause for a > bit?? Bad block remapping is typical culprit.
I hope you didn't think I propose to wait until end-user access tobad block :). > > 2) I can keep an unlimited amount of storage scrubbed and free of > parity/ECC/read errors 24x7 without any CPU overhead and negligible disk > overhead with LINUX when using the built-in md driver. No need to do > manual consistency check/repairs. Not even zfs will protect against > data loss if you have a drive failure AND bad blocks on different disks, > unless you add more disk to the pool. > > 3) I can manually scan & fix bad blocks in 1TB in a few hours with near > zero CPU overhead, or it could be 1000TB. Doesn't matter, it will take > same amount of time assuming same make/model of disk. Granted I don't > look at the file system, but I don't need to, thanks to zfs. I also > scan every block, including unallocated space. Zfs won't bother with > those. The scanning will also repair weak sectors that haven't died > yet, but are about to. So I can add another level of reliability & > availability. > If I know where the bad blocks are ahead of time, I can force a repair > before the movie gets streamed, so there will be no I/O interruption. I don't see why file-system can't do the same (not sure if zfs as it is does scrubbing, but why not). Definitive pros for integrating scrubbing into file-system are I/O scheduling (file-system can initiate scrubbing more intelligently than any external tool) and capacity accounting (each bad block remapping decreases disk capacity, right?). Alternatively, this could be done at disk firmware level, fully transparent to file-system. Simple approach with remapping disk driver I have suggested in the earlier mail achieves the same albeit at host level. Regards, Andrey > > Sorry, sounds like commercial here, but as you can see, there are some > real benefits for intelligent background scrubbing. > > -----Original Message----- > From: Andrey Kuzmin [mailto:[EMAIL PROTECTED] > Sent: Tuesday, April 15, 2008 3:59 PM > To: David Lethe > Cc: [email protected] > Subject: RE: [storage-discuss] Repairing known bad disk blocks before > zfs encounters them > > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:storage-discuss- > > [EMAIL PROTECTED] On Behalf Of David > > Sent: Tuesday, April 15, 2008 11:54 PM > > To: [email protected] > > Subject: [storage-discuss] Repairing known bad disk blocks before zfs > > encounters them > > > > I have some code that implements background media scanning so I am > able to > > detect bad blocks well before zfs encounters them. I need a script > or > > something that will map the known bad block(s) to a logical block so I > can > > force zfs to repair the bad block from redundant/parity data. > > Not sure why do you need that extra intelligence :). File-system will > discover bad block on read and do automatic relocation, so why bother? > > > <snip> > > It seems as if zfs's is too smart for it's own good and won't let me > fix > > something that I know is bad, before zfs has a chance to discover it > for > > itself. :) > > Well, you can write a generic disk driver that will do bad block > discovery, > map maintenance and remapping on access, but I have reasons to believe > you'd > be re-implementing parts of zfs. > > Regards, > Andrey > > > > > > > This message posted from opensolaris.org > > _______________________________________________ > > storage-discuss mailing list > > [email protected] > > http://mail.opensolaris.org/mailman/listinfo/storage-discuss > > _______________________________________________ storage-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/storage-discuss
