lkml.org 
[lkml]   [2000]   [Sep]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectBug in block device read/write!
[kernel-2.4.0-test3 to kernel-2.4.0-test8-pre6, bug present in those two, 
didn't try others]

Hi all,

I have been trying to get the linear md driver to work with NTFS volumes
for several months and it never worked. - I was suspecting the NTFS driver
(after having fixed linear md and verified that at least that worked fine)
but today I finally found why it doesn't work:

There is a bug in reading/writing to block devices. - It manifests itself
in the form that partitions are too small by exactly one sector!

Even though a cfdisk shows that a partition has a certain number of
sectors, you can never seek + read and/or write to the last sector (doing
file i/o using read/write(2) [also tried fread/fwrite(3), same result]. -
Last sector doesn't seem to exist. However reading the actual hd (/dev/hdb
or /dev/sda, ie. affects both IDE and SCSI) instead of the partition
(/dev/hdb7 or whatever) the sector does exist and contains the expected
information!

This is obviously something that would go unnoticed most of the time but
when you use linear raid you then of course end up having all data after
the first partition being misaligned by one sector and hence you are fscked
in the real sense of the word. (You can kiss the partition good bye if you
write to it.) - Obviously if the partitions were created and formatted by
linux then the bug would never be noticed since the sector just doesn't
exist but when you are using both windows and linux the "delta one sector"
makes a big difference...

Doing a bitwise comparison of /dev/md0 (linear raid) with the partitions it
is made up of (/dev/hdb7 and 9) shows 100% match so not a problem in the
linear raid code AFAICS.

Also this affects both scsi and ide so probably not in the subsystem code
but it could be that the code was just duplicated when written(?) so I
thought I would look at all of it and take the opportunity to familiarise
myself with those parts of the kernel.

My thinking is, that this is a offset by one error somewhere in the
VFS/generic block device layer somewhere, however having never looked at
any of the IDE/SCSI/block device code before today I wasn't able to see
anything obviously wrong anywhere (I looked at for example:
drivers/scsi/sd.c, drivers/ide/ide.c, hd.c, etc., fs/partitions/check.c,
msdos.c, drivers/block/ll_rw_block.c et al, fs/block_dev.c). And it is
getting rather late now and my brain is falling asleep... )-:

Anyway, I thought I would report this in the hope someone will jump and say
"I know what that is!" Otherwise I will follow it up myself this weekend
and hopefully spot the little bugger.

Regards,

Anton
--

"Education is what remains after one has forgotten everything he
learned in school." - Albert Einstein

--
Anton Altaparmakov Voice: 01223-333541(lab) / 07712-632205(mobile)
Christ's College eMail: AntonA@bigfoot.com
Cambridge CB2 3BU ICQ: 8561279
United Kingdom WWW: http://www-stu.christs.cam.ac.uk/~aia21/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 12:41    [W:0.148 / U:0.328 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site