I posted this to linux-kernel before I found this list. 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: [EMAIL PROTECTED]
