Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.carno.net.au!harbinger.cc.monash.edu.au!news.mel.connect.com.au!munnari.OZ.AU!news.ecn.uoknor.edu!solace!mn6.swip.net!seunet!news2.swip.net!nike.volvo.se!cyklop.volvo.se!peter From: peter@cyklop.volvo.se (peter hakanson) Newsgroups: comp.unix.bsd.bsdi.misc Subject: Re: BSDI 2.1, file systems > 4gb and off_t Date: 24 Mar 1997 08:00:03 GMT Organization: Volvo Corp. Lines: 77 Message-ID: <5h5ca3$74h@nike.volvo.se> References: <E7JAKK.B7p@spdcc.com> NNTP-Posting-Host: cyklop.volvo.se X-Newsreader: TIN [version 1.2 PL2] Xref: euryale.cc.adfa.oz.au comp.unix.bsd.bsdi.misc:6448 Steve, we have used 9Gbyte scsi disks since 2.0.1 2.0 had a problem when a file grow beyond 4 Gbyte, but 2.1 has no prblem whatsoever with big discs. We used adaptec 1542CP/CF and seagate 9Gbyte. Maybe your trouble is connected to eide ? Peter h Steve Dyer (dyer@spdcc.com) wrote: : I've been having a LOT of trouble installing a Maxtor 5.1gb EIDE drive : into a system running BSDI 2.1 (I described this in more detail a : few weeks ago). I partitioned the drive using disksetup, with the : usual small root (a) and swap (b) partitions, with the remaining 'h' : partition using the rest of the drive's sectors. This 'h' partition is : 9772560 512-byte sectors in length. A "newfs" followed by a mount : works fine, but once the file system starts getting written to, it begins : to develop errors (directories changing to garbage inodes, etc.) : and the system inevitably crashes. : I was a bit worried about the EIDE installation, but double-checked : everything, and it seems OK. So, I then worried whether I was seeing : 4bg wraparound within the filesystem code. I wrote a user-level test : program which writes over each block in the unmounted 'h' partition : with a array of 64 quad_t integers, with each array element containing : the ordinal sector number of the sector. So, sector 0 contains an array : of 64 zeroes (each 8 bytes lone), sector 100 ... 64 100's, and so on. : for each sector b from 0 until the end of the partition (sector 9772560) : fill a buffer representing the sector with its ordinal position : in each 8-byte longlong integer (fill in the buffer with 64 : copies of the integer b) : set the write byte offset into the disk partition to b * 512 : bytes (this is an 8 byte long-long quantity, as supposedly is the : BSDI internal representation of the write offset) : write the sector buffer into the partition (using the : just determined write offset) : endfor : I'm using lseek(fh, b*512, SEEK_SET), and 'b' is of type off_t. : Sizeof(off_t) is 8. It appears that the lseek works fine (that is, : I'm not accidentally passing a 32-bit long quantity to lseek), : because everything works fine until b reaches 8388608. : 8388608*512 is (da-da!) 2^32. And, in fact, we then start : seeing wraparound, with blocks 0, 1, 2 and so forth getting : overwritten. Why should this be, given that off_t is : a quad_t (8-byte 64-bit integer) in BSDI 2.1, and that internally, : all the kernel calculates file offsets in terms of off_t/quad_t : data types? : I also don't know whether this test program is a red herring, but : it's sure consistent with the corruption I see when this file : system is mounted and allowed to be written for 10-15 minutes : during a restore. : Somehow I suspect I'm misunderstanding something fundamental : about BSDI 2.1's handling of disk partitions and file systems : larger than 8388608 sectors, and the use of lseek with off_t offsets. : Can anyone comment? : -- : Steve Dyer : dyer@ursa-major.spdcc.com -- -- <peter.devnull@cyklop.volvo.se> (remove ".devnull" before use!) Peter Hakanson VolvoData Dep 2580 phone +46 31 66 74 27