l i n u x - u s e r s - g r o u p - o f - d a v i s
L U G O D
 
Next Meeting:
September 2: Social gathering
Next Installfest:
TBD
Latest News:
Aug. 18: Discounts to "Velocity" in NY; come to tonight's "Photography" talk
Page last updated:
2003 Jun 13 06:03

The following is an archive of a post made to our 'vox-tech mailing list' by one of its subscribers.

Report this post as spam:

(Enter your email address)
Re: [vox-tech] Linux Block Layer is Lame (it retries too much)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [vox-tech] Linux Block Layer is Lame (it retries too much)



--6Vw0j8UKbyX0bfpA
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, May 28, 2003 at 03:09:21PM -0400, Mike Simons wrote:
> On Wed, May 28, 2003 at 11:31:56AM -0700, Jeff Newmiller wrote:
> > On Tue, 27 May 2003, Mike Simons wrote:
> > >   Last week I was having problems with the ide layer... it retries
> > > way too many times.  I was trying to read 512 byte blocks from a dying
> > > /dev/hda (using dd_rescue which calls pread), for each bad sector the
> > > kernel would try 8 times,=20
[...]
> > > - Any other ideas on how to pull the disk blocks?
> >=20
> > Not easy ones. (Build your own device driver that doesn't use mmap.)
>=20
>   Michael Wenk suggested using O_DIRECT on the open call, which is
> an excellent idea.  This was what the Oracle people at their Clustering=
=20
> Filesystem talk.  I have one more failing hard drive around which I'm=20
> going to try that on...=20

On Wed, May 28, 2003 at 02:58:30PM -0700, Michael Wenk wrote:
> The other thing I was looking at was an ioctl call for BLKRASET,
> or BLKFRASET.
[...]
> Maybe this or the ioctl will help(or possibly O_DIRECT) =20

  I changed dd_rescue to use O_DIRECT, and that required a minor change
to the malloc to posix_memalign for the buffer since O_DIRECT requires
that the memory buffer be aligned.  It seems to work very nicely, only
one retry per block... transfer from bad drive was happening near the
normal drive transfer rate (which isn't much on a laptop drive).

  Unfortunately the failure mode of the second drive was slightly
different from the previous one, so there weren't hundreds of bad=20
sectors, and even the bad regions were readable after a number of=20
retries.  I'll wait for the next failed disk to confirm things work
great with that option.  :)

--=20
GPG key: http://simons-clan.com/~msimons/gpg/msimons.asc
Fingerprint: 524D A726 77CB 62C9 4D56  8109 E10C 249F B7FA ACBE

--6Vw0j8UKbyX0bfpA
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE+6Lcz4Qwkn7f6rL4RArvaAJ9/kH27ws+9at+ESNBiKkU0+D9nvQCdFjFM
P08+yISGVyQoi0Ol999w3lQ=
=dMI4
-----END PGP SIGNATURE-----

--6Vw0j8UKbyX0bfpA--
_______________________________________________
vox-tech mailing list
vox-tech@lists.lugod.org
http://lists.lugod.org/mailman/listinfo/vox-tech








LinkedIn
LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
facebook
LUGOD Group on Facebook
'Like' LUGOD on Facebook:

Hosting provided by:
Sunset Systems
Sunset Systems offers preconfigured Linux systems, remote system administration and custom software development.

LUGOD: Linux Users' Group of Davis
PO Box 2082, Davis, CA 95617
Contact Us

LUGOD is a 501(c)7 non-profit organization
based in Davis, California
and serving the Sacramento area.
"Linux" is a trademark of Linus Torvalds.

Sponsored in part by:
Sunset Systems
Who graciously hosts our website & mailing lists!