Help: pdisk/cam problem, even more info

**** Here is the short version: ****

I'm using a 486dx2/66 with 32meg RAM, an adaptec 1542C, 2 1gb
quantums, 1 350meg Maxtor, 1 CDROM and 1 4mm DAT drive, VSTa is on
the DOS partition on the 1st Quantum (sd0_dos0) and it works fine.

For some reason reads to certain partitions will only read 4096 bytes
per "read()" call. Successive calls can read the foFrom vandys@puli.cisco.com Thu Jun 29 18:11:34 1995
Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id SAA00101; Thu, 29 Jun 1995 18:11:33 -0700
Received: from terra.igcom.net (jeske@terra.igcom.net [204.251.176.2]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with ESMTP id AAA06354 for <vsta@cisco.com>; Wed, 28 Jun 1995 00:21:18 -0700
Received: (from jeske@localhost) by terra.igcom.net (8.6.12/8.6.10) id CAA28789 for vsta@cisco.com; Wed, 28 Jun 1995 02:12:53 -0500
From: David Jeske <jeske@igcom.net>
Message-Id: <199506280712.CAA28789@terra.igcom.net>
Subject: RAMDISK filesystem idea/question
To: vsta@cisco.com
Date: Wed, 28 Jun 1995 02:12:53 -0500 (CDT)
X-Url: <URL:http://www.cen.uiuc.edu/~jeske>
Reply-To: jeske@uiuc.edu
X-Mailer: ELM [version 2.4 PL24]
Content-Type: text
Content-Length: 1810
llow
I noticed this in a post about boot floppys a short while back,
I'm not sure who wrote what:

>> Sounds quite reasonable. You might want to enhance srv/tmpfs to permit
>> subdirectories. Or, you could run a filesystem on top of GNU zip on
>> top of the compressed data (but then you have to leave the floppy in
>> the drive).

is there any reason that a static RAMDISK filesystem could not be
created by making a server which just allowed file-access to a pre-sized
piece of RAM and then running a fileing bytes just
fine, but again, it always returns having read only 4096 bytes. (or
less if you asked for less)

The only pattern I can see is that all of the problems occur reading
partitions over the "512mb" mark on the hard drives. Which leads me to
believe it's really a pdisk, or a pdisk/cam relationship
problem. Since "standard" drive size information imposes a 512MB limit
(512bytes/sector * 1024sectors?? I'm not sure if that's where the
limit comes from or something else, i'm a bit foggy)

I've also observed that when working the the raw "sd0" device, I can
not read any data past byte 262144, or in other words, I can't read
any sector above 511.

So if you have any idea why pdisk or cam would have problems with
drives over 512MB or space on drives over the 512MB mark... please
read on.

**** Here issystem on top of that? Not that
it would be the most efficient way to do it, but is there any significant
reason NOT to do it? The more I think about this the more stupid and
wastefull it sounds, so I guess it's kind of a silly idea, however, it's
late and I can have silly ideas.

Is the compression algorithm used by GNU zip suitable for random access
to the underlying data? I was under the impression that it was VERY
stream oriented. (not that another compression could not be used in the
middle, I was just wondering about G the long version: ****

As I explained in the last two messages, I've been having trouble
accessing certain partitions on my SCSI drives. For some reason, some
partitions will only read 4096 bytes with each "read()"
call. Successive "read()" calls can read the information which follows
just fine, so it's not that there is something at a particular
location which stopped the read.

I've been sludging through cam and pdisk code and I can't find any
obvious logical reason that my problem persists. I understand wNU zip)

I suppose one advantage of enhancing srv/tmpfs instead is that it would
not have to be statically sized. However, this might be a disadvantage in
the case of a boot-floppy.

>Something like tcx might work too. Of course another highly desireable
>feature for this would be some sort of execute-in-place facility for
>memory-mapped filesystems (I'm not sure if tmpfs does this or not). It's
>something I'd like to get working for use with some memory mapped flash
>filesystems. Basically just map the code directly, and usehy the
magic number is 4096 bytes though. The cam code cuts up requests into
4096 byte calls to the adaptor. When a read is made to a partition
which exhibits the problem, the first read to the adaptec is
successfull, while the second one returns having read 0 bytes.

I don't understand why it occurs on a partition by partition basis though.
Which is why I started looking at the pdisk code. Unfortunatly, I still
don't have any leads on what specifically would be causing it so I thought
I would throw out some more i the data
>copy-on-write.

I'm fairly sure that doing execute-in-place of a RAM based program
THROUGH another filesystem driver would not be possible. (or at least it
would be more difficult than writing a native XIP server)

nformation I gained from testing and hope
someone else has some ideas. Right now, my best guess is that it has to do
with the magic "512mb" size associated with "standard" drive size
information. (the 512bytes/sector 1024sector limit) However, I'm still
learning how the whole pdisk/cam relationship works to find out how this
would factor in.

I wrote a small test program which does successive reads starting at
1k and incrementing up by 1k each iteration until it reaches 10k. I
ran the program on every partition I have available. There are three
partitions which "fail" and can only read 4096 bytes per "read()". All
other partitions work fine. The partitions which "fail" do it
consistantly, I can reboot and such and they still "fail". The three
partitions which fail are:

sd0_lxnat0
sd1_lxswap0
sd1_dos0

Here is the partition information for all three drives from Linux
fdisk. I marked the partitions which have problems under VSTa. Of
course I have no problems under any other operating systems.

**** My first hard drive: (1gb, Quantum 1080S, sd0)

Disk /dev/sda: 64 heads, 32 sectors, 1029 cylinders
Units = cylinders of 2048 * 512 bytes

   Device Boot Begin Start End Blocks Id System
/dev/sda1 1 1 420 430064 a7 Unknown
/dev/sda2 * 421 421 421 1024 a OS/2 Boot Manager
/dev/sda3 422 422 721 307200 6 DOS 16-bit >=32M
/dev/sda4 722 722 1029 315392 83 Linux native <--fail
Partition 4 has different physical/logical endings:
     phys=(1023, 63, 32) logical=(1028, 63, 32)

**** My second hard drive: (1gb, Quantum 1080S)

Disk /dev/sdb: 64 heads, 32 sectors, 1029 cylinders
Units = cylinders of 2048 * 512 bytes

   Device Boot Begin Start End Blocks Id System
/dev/sdb1 1 1 300 307184 7 OS/2 HPFS
/dev/sdb2 301 301 821 533504 83 Linux native
/dev/sdb3 822 822 842 21504 82 Linux swap <--fail
/dev/sdb4 843 843 1029 191488 5 Extended
Partition 4 has different physical/logical endings:
     phys=(1023, 63, 32) logical=(1028, 63, 32)
/dev/sdb5 843 843 1029 191472 6 DOS 16-bit >=32M <--fail

**** My third hard drive: (350meg, Maxtor)

Disk /dev/sdc: 64 heads, 32 sectors, 329 cylinders
Units = cylinders of 2048 * 512 bytes

   Device Boot Begin Start End Blocks Id System
/dev/sdc1 1 1 329 336880 a7 Unknown
 
****
Received on Thu Jun 29 18:10:18 1995