cedman@golem.ps.uci.edu (Carl Edman) (11/11/90)
In article <1990Nov10.190318.18938@maverick.ksu.ksu.edu> brtmac@maverick.ksu.ksu.edu (Brett McCoy) writes: In <1990Nov9.170337.9484@onion.pdx.com> jeff@onion.pdx.com (Jeff Beadles) writes: >In <1008@intelisc.isc.intel.com> cfj@isc.intel.com (Charlie Johnson) writes: >>I'm curious if the companies who support Unix on large systems made the >>necessary file system changes to allow individual files which are larger >>than 4 gigabytes ?? You'd have to at least stretch the file size in the >>inode beyond 32 bits and possibly mess around in the super block. Any >>comments ?? >Well, that would take one big disk :-) Unix files can not span physical disk >partitions, at least on more common version of Unix. (Has anyone changed this?) Unless what I read recently is totally bogus, the latest version of AIX, the version that is on the new RS/6000 machines, has support for spanning filesystems across multiple disks. It does this deep down in the kernal so that to filesystem sees the multiple disks as a single volume. It actually has support for quite a few tricks including disk mirroring. How much of this is actually usable right now I don't know, but supposedly it does work. Now this would be really funny. All versions of AIX I had the lack of pleasure of having to use so far had quite the opposite problem: No files larger that 4 MBytes Trting to transfer large files like e.g. the emacs source to port it a.s.o. required me to place the archive on another nearby machine, split it in 2, transfer the parts and the reassemble all files in a directory on the Risc System 6000. Possibly this has been fixed in the later releases. Having files span filesystems won't do you much good unless you can use large files. Note: AIX really isn't comp.unix.large, so I have changed the direction of this thread to comp.unix.aix. Carl Edman Theorectical Physicist,N.:A physicist whose | Send mail existence is postulated, to make the numbers | to balance but who is never actually observed | cedman@golem.ps.uci.edu in the laboratory. | edmanc@uciph0.ps.uci.edu
vvawh@convx1.lerc.nasa.gov (Tony Hackenberg) (11/12/90)
-- Tony Hackenberg NASA/Lewis Research Center M.S.142-2, 21000 Brookpark Rd., Cleveland, OH 44135 Internet: vvawh@convx1.lerc.nasa.gov Phone: (216) 433-5201 (work) Opinions are mine & do NOT represent any official position by my employer.
richard@locus.com (Richard M. Mathews) (11/12/90)
cedman@golem.ps.uci.edu (Carl Edman) writes: >Now this would be really funny. All versions of AIX I had the lack of >pleasure of having to use so far had quite the opposite problem: > No files larger that 4 MBytes (The referenced message had "Followup-To: comp.unix.aix", but it would be unfair for this incorrect claim to go uncorrected in comp.unix.large) AIX (at least the versions with with I am familiar) has a default ulimit of 4 MB. This can be changed on a per system, per user, or per process basis (but, of course, only a root process can increase its limit). Ulimit goes way, way back in the history of Unix and is not specific to AIX. Richard M. Mathews Freedom for Lithuania Locus Computing Corporation Laisve! richard@locus.com lcc!richard@seas.ucla.edu ...!{uunet|ucla-se|turnkey}!lcc!richard
zzassgl@uts.mcc.ac.uk (Geoff Lane) (11/12/90)
UTS 2.0 allowed a file as large as a single physical disk. We have had user files > 50 MB i n size. UTS 2.1 will allow files greater than a physical disk by creating virtual devices from a number of smaller physical drives.: -- Geoff. Lane. Janet: zzassgl@uk.ac.mcc.cms UTS Sys Admin, Manchester Computing Centre, Oxford Rd, Manchester, M13 9PL
garyf@ncsa.uiuc.edu (Gary Faulkner) (11/13/90)
In article <1990Nov11.225759.866@ceres.physics.uiowa.edu> vvawh@convx1.lerc.nasa.gov (Tony Hackenberg) writes: > I think Amdahl's UTS2.1 will also have this ability. Isn't it true that now that systems such as UTS, Unicos, etc. have the ability to have LOCAL files >4MB, NFS files are a problem. For instance, it is feasible (I believe) to have a file which is, let's say, 15GB (easily on a 12 wide stripe of 1.5 GB disks). Anyway, isn't it true that NFS will not support reading past a certain byte of said file?? Gary Faulkner Nat'l Center for Supercomputing Applications University of Illinois - Urbana/Champaign All these thoughts are my own, not my employer's...
vvawh@convx1.lerc.nasa.gov (Tony Hackenberg) (11/13/90)
I think Amdahl's UTS2.1 will also have this ability. Message-ID: <1990Nov12.020449.8659@eagle.lerc.nasa.gov> Date: 12 Nov 90 02:04:49 GMT References: <1008@intelisc.isc.intel.com> <1990Nov9.170337.9484@onion.pdx.com> <1990Nov10.190318.18938@maverick.ksu.ksu.edu> <CEDMAN.90Nov10200403@lynx.ps.uci.edu> Reply-To: vvawh@convx1.lerc.nasa.gov (tony hackenberg) Distribution: usa Organization: NASA/Lewis Research Center, Cleveland Lines: 6 -- Tony Hackenberg NASA/Lewis Research Center M.S.142-2, 21000 Brookpark Rd., Cleveland, OH 44135 Internet: vvawh@convx1.lerc.nasa.gov Phone: (216) 433-5201 (work) Opinions are mine & do NOT represent any official position by my employer.
klaus@cnix.uucp (klaus u schallhorn) (11/14/90)
======================================================================== In article <4844.273dc08e@infocomm.com> vvawh@convx1.lerc.nasa.gov (Tony Hackenberg) writes: > > I think Amdahl's UTS2.1 will also have this ability. >Message-ID: <1990Nov12.020449.8659@eagle.lerc.nasa.gov> >Date: 12 Nov 90 02:04:49 GMT >References: <1008@intelisc.isc.intel.com> <1990Nov9.170337.9484@onion.pdx.com> <1990Nov10.190318.18938@maverick.ksu.ksu.edu> <CEDMAN.90Nov10200403@lynx.ps.uci.edu> >Reply-To: vvawh@convx1.lerc.nasa.gov (tony hackenberg) >Distribution: usa >Organization: NASA/Lewis Research Center, Cleveland >Lines: 6 >======================================================================= HEY, I BELIEVE YOU. JUST TELL ME: why are out of the 19 messages I have in this newsgroups 13 [thirteen] identical as far as the marked bit goes? Is this the way you guys build the shuttle? > >-- >Tony Hackenberg >NASA/Lewis Research Center M.S.142-2, 21000 Brookpark Rd., Cleveland, OH 44135 >Internet: vvawh@convx1.lerc.nasa.gov Phone: (216) 433-5201 (work) >Opinions are mine & do NOT represent any official position by my employer. klaus -- George Orwell was an Optimist
littauer@uts.amdahl.com (Tom Littauer) (11/15/90)
In article <1990Nov12.173130.16222@ux1.cso.uiuc.edu> garyf@ncsa.uiuc.edu (Gary Faulkner) writes: > >Isn't it true that now that systems such as UTS, Unicos, etc. have the >ability to have LOCAL files >4MB, NFS files are a problem. Correct. > For instance, >it is feasible (I believe) to have a file which is, let's say, 15GB >(easily on a 12 wide stripe of 1.5 GB disks). You don't have to stripe to have big files, but then with big files you probably want to. The tranfer rate of the file system you describe would be about 20 MegaBytes/sec sustained. > Anyway, isn't it true that >NFS will not support reading past a certain byte of said file?? Yes, it's true. Until Sun defines the architectural change, us vendors of big face the ugly choice between limits on NFS file size and non-standard implementations. So far, we're in the limit camp. As more people create big files they want to get at with NFS, we'll probably change (not to mention lobbying with UI and Sun :-). -- UUCP: littauer@amdahl.amdahl.com or: {sun,decwrl,hplabs,pyramid,ames,uunet}!amdahl!littauer DDD: (408) 737-5056 USPS: Amdahl Corp. M/S 278, 1250 E. Arques Av, Sunnyvale, CA 94086 I'll tell you when I'm giving you the party line. The rest of the time it's my very own ravings (accept no substitutes).
patrick@convex.COM (Patrick F. McGehearty) (11/15/90)
In article <5epo02S6e6i501@amdahl.uts.amdahl.com> littauer@amdahl.uts.amdahl.com (Tom Littauer) writes: >Yes, it's true. Until Sun defines the architectural change, us vendors of >big face the ugly choice between limits on NFS file size and non-standard >implementations. I agree. Increasing the NFS file size limits requires either Sun to extend its architecture or for several "large system" vendors to get together and agree on a "large-file" extension. I would prefer Sun to bless any architecture extension to reduce the likelihood of varying (and buggy) implementations. However, large system vendors do not have a lot of influence with Sun (small unit volumes, lower fees) as compared to low-unit-cost-high-volume customers. If users who had both workstations and large systems started requesting large-file support in NFS, maybe it would get more attention. - Patrick McGehearty Disclaimer: The above is my personal opinion and does not represent the policies of Convex Computer Corporation.
src@scuzzy.in-berlin.de (Heiko Blume) (11/16/90)
garyf@ncsa.uiuc.edu (Gary Faulkner) writes: >In article <1990Nov11.225759.866@ceres.physics.uiowa.edu> >vvawh@convx1.lerc.nasa.gov (Tony Hackenberg) writes: >> I think Amdahl's UTS2.1 will also have this ability. >Isn't it true that now that systems such as UTS, Unicos, etc. have the >ability to have LOCAL files >4MB, NFS files are a problem. For instance, >it is feasible (I believe) to have a file which is, let's say, 15GB >(easily on a 12 wide stripe of 1.5 GB disks). Anyway, isn't it true that >NFS will not support reading past a certain byte of said file?? what a coincidence: i read today, that UTS 2.1 allows files as big as 6 TB (that TeraByte). *without* loosing in the compatibility issue. i wonder how they accomplish that. there must be some problems left like an old application doing a stat() on a 1TB file etc. -- Heiko Blume <-+-> src@scuzzy.in-berlin.de <-+-> (+49 30) 691 88 93 public source archive [HST V.42bis]: scuzzy Any ACU,f 38400 6919520 gin:--gin: nuucp sword: nuucp uucp scuzzy!/src/README /your/home
thad@cup.portal.com (Thad P Floryan) (11/17/90)
src@scuzzy.in-berlin.de (Heiko Blume) in <1990Nov16.005428.12747@scuzzy.in-berlin.de> writes: >In article <1990Nov11.225759.866@ceres.physics.uiowa.edu> >vvawh@convx1.lerc.nasa.gov (Tony Hackenberg) writes: >> I think Amdahl's UTS2.1 will also have this ability. what a coincidence: i read today, that UTS 2.1 allows files as big as 6 TB (that TeraByte). *without* loosing in the compatibility issue. i wonder how they accomplish that. there must be some problems left like an old application doing a stat() on a 1TB file etc. Probably they just store the same data 27 times, much like the recent postings reminding us that "Amdahl's UTS2.1 will ..." :-) As long as we're getting silly (it's been a long week), how about this idea for compression: compress your 1TB file down to 8 bytes simply by noting the file contains only 0's and 1's, so throw-away all the zeroes with our knowledge zero means nothing, then, since they're only 1's left, count THEM up and store the count as a 64-bit double integer. :-) Seriously, the issue of "large" files is of concern to me since I'm porting my company's major product to UNIX. Many present clients' files typically exceed 500MB and I'm curious how such files ARE handled on "typical" UNIX systems in terms of backup recovery, performance, and any other germane topics. My personal belief is that supporting such large files presents a maintenance and performance nightmare; 'twould be better to have a "file of files" which could point to many (smaller) physical files and treat them as "one" large logical file; this technique could be extended ad infinitum for logical files up to the limits of on-line mass storage. Comments? Thad Floryan [ thad@cup.portal.com (OR) ..!sun!portal!cup.portal.com!thad ]
ikluft@uts.amdahl.com (Ian Kluft) (11/20/90)
In article <108780@convex.convex.com> patrick@convex.COM (Patrick F. McGehearty) writes: >Increasing the NFS file size limits requires either Sun to >extend its architecture or for several "large system" vendors to get >together and agree on a "large-file" extension. I would prefer Sun >to bless any architecture extension to reduce the likelihood of >varying (and buggy) implementations. However, large system vendors do not >have a lot of influence with Sun (small unit volumes, lower fees) as >compared to low-unit-cost-high-volume customers. [...] The forum you're looking for is called Unix International (UI). It includes members such as AT&T, Sun, Amdahl, and everyone else that is developing SVR4. (Sorry for the short list... it should be obvious why I only remember those three.) I don't know if UI is currently discussing that issue. But if it is going to be considered, that's where I expect it would have the best chance. -- Ian Kluft ----------------------------- # Another flying fanatic UTS Systems Software \ |--*--| / # PP-ASEL Amdahl Corporation C - 172 /\___/\ Skyhawk # Member AOPA, ACM, UPE Santa Clara, CA o o o #include <std-disclaimer>