I hope this is the correct place to post this. Please respond directly
to
me as I am not on this list.
General Dynamics has given me a contract to build a Linux server that
can mount a Digital Unix SCSI II drive and make the files available to
Windows workstations for reading and deleting via samba. They have
provided me with three sample drives, all 9.1 GB Quantum Atlas II’s with
50 pin SCSI interface.
This is a commercial contract so there is money for you if you can help
me solve this Beyond that I think it would be good for Linux. . General
Dynamics is looking for Linux solutions because the government has
mandated it. I want to show them that Linux can deliver.
That being said, on to the technical details and problems.
My workstation is a basic Pentium III w’ 128MB Ram & 18GB LVD system
drive. It is running RH6.2 and for this job I am working with the
2.3.99pre8 kernel.
The sample drives appear to have the OSF partition type and the UFS file
system. (DEC OSF/1 ?). With CONFIG_UFS_FS, CONFIG_UFS_FS_WRITE and
CONFIG_OSF_PARTITION set in the kernel,
I can mount the disk with a command like:
mount –t ufs –o ufstype=sun /dev/sdb3 /du1
Then I can read the dir & inode table (ls –l) and can read short files
okay, but long files get truncated at 98304 bytes. ( 192 * 512 = 98304
). This has been the case on two different drives and two different
files, and are the only samples I have that are longer than 98304.
The command:
cp –v /du2/oilstock .
returns the error:
cp: /du2/oilstock.tar: Input/output error
and in /var/log/messages:
May 30 05:43:46 GD-DU kernel: attempt to access beyond end of device
May 30 05:43:46 GD-DU kernel: 08:23: rw=0, want=536934401, limit=8890760
May 30 05:43:46 GD-DU kernel: attempt to access beyond end of device
May 30 05:43:46 GD-DU kernel: 08:23: rw=0, want=536934402, limit=8890760
..
Those ‘want’ numbers look way out of line to me. Is something getting
screwed up in the way the block numbers are being read?
I can remount the drive rw. This doesn’t change the above read problem.
However I can write to the ufs drive, and write and read back long
files, like my sample linux-2.3.99pre8.tar.gz (20MB)
So I have a problem reading long files that are native (but not long
files written by Linux).
Looking at ufs_fs.h it appears UFS_BLOCK_SIZE = 8192. What does
UFS_NDADDR = 12 mean? Does it mean 12 block addresses directly in
the inode because 12 * 8192 = 98304, which allows the rather tidy
answer that the system is getting the direct addressing right but
mis-reading the indirect addresses written on the DEC system, while
reading its own writing of those addresses fine.
Could this problem be related to the fact that the fs and files were
written on a 64 bit system (Alpha, I assume) were as I am working on a
32 bit system (i386)? If that is the case how do I fix it?
Any light you can throw on this problem will be much appreciated.
--Clay J. Claiborne, Jr., President
Cosmos Engineering Company 1550 South Dunsmuir Ave. Los Angeles, CA 90019
(323) 930-2540 (323) 930-1393 Fax
http:www.CosmosEng.com
Email: cjc@cosmoseng.com
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed May 31 2000 - 21:00:23 EST