Article View: comp.sys.amiga.tech
Article #4702Re: when is a block not a block?
From: Kim DeVaughn
Date: Sun, 05 Aug 1990 02:44
Date: Sun, 05 Aug 1990 02:44
57 lines
3090 bytes
3090 bytes
In article <13615@cbmvax.commodore.com> jesup@cbmvax (Randell Jesup) writes:
>
> We'll report the amount of space left, but neither we nor Unix (nor
> I suspect VMS) guarantee a specific number of blocks used to store a file.
> Unix is slightly less variable, due to preallocation of inodes, but even it
> varies (bsd storing of small files in partial blocks, etc).
That's fine. I wasn't looking for any "guarantees". Is it possible that you
can do the same for the actual number of blocks (or some variant thereof) used
by a file via fib_NumBlocks or a similar mechanism?
> The caller should be aware that since it doesn't know exactly the
> algorithms used by the filesystem to store the data, there's no way to be
> certain of your interpretation of whether the file will fit (even if nothing
> else is happening).
True, but it can be a real good "sanity check" at times. No guarantees tho.
> It's fairly simple to write a file of null/garbage data of the given
> length, and see whether it succeeds (or under 2.0 use SetFileSize to get the
> filesystem to do it for you - even faster).
2.0 sounds better and better all the time! Thanks for all the "goodies"!
> >When and where will
> >all this "good stuff in 2.0" be documented (for the masses)?
>
> Get the Atlanta Devcon notes from CATS.
I wasn't aware that they were available yet? What's the cost ... my check is
all made out except for that item ... :-)
> That doesn't work if the allocation sizes are variable (there are
> other gotcha's as well). I think my previous statement stands: the size
> reported is a reasonable approximation, but there can be no guarantee of
> correlation with other values/objects.
I've run into one (pathass), as I mentioned in a previous posting, but that
was won a "logical" psuedo-device. What real devices vary their allocations
in the way you're suggesting?
Thanks for all the info on this stuff Randell ... it is appreciated, and may
keep a few of us from falling in a deep, dark hole in the future!
/kim
--
UUCP: kim@uts.amdahl.com -OR- ked01@juts.ccc.amdahl.com
or: {sun,decwrl,hplabs,pyramid,uunet,oliveb,ames}!amdahl!kim
DDD: 408-746-8462
USPS: Amdahl Corp. M/S 249, 1250 E. Arques Av, Sunnyvale, CA 94086
BIX: kdevaughn GEnie: K.DEVAUGHN CIS: 76535,25
Technical Details
Message-ID:
<d9sf02ij01gn01@JUTS.ccc.amdahl.com>Path:
arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!ucsd!pacbell.com!pacbell!amdahl!JUTS!ked01References:
<6498.269a4527@vax1.tcd.ie> <648H02l0b8KM01@amdahl.uts.amdahl.com> <13237@cbmvax.commodore.com> <3fco02lsb9LE01@amdahl.uts.amdahl.com> <13342@cbmvax.commodore.com> <c4pK02n=01EQ01@JUTS.ccc.amdahl.com> <13571@cbmvax.commodore.com> <d4eQ02U2010201@JUTS.ccc.Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!ucsd!pacbell.com!pacbell!amdahl!JUTS!ked01 From: ked01@ccc.amdahl.com (Kim DeVaughn) Newsgroups: comp.sys.amiga.tech Subject: Re: when is a block not a block? Summary: whenever ... Message-ID: <d9sf02ij01gn01@JUTS.ccc.amdahl.com> Date: 5 Aug 90 02:44:31 GMT References: <6498.269a4527@vax1.tcd.ie> <648H02l0b8KM01@amdahl.uts.amdahl.com> <13237@cbmvax.commodore.com> <3fco02lsb9LE01@amdahl.uts.amdahl.com> <13342@cbmvax.commodore.com> <c4pK02n=01EQ01@JUTS.ccc.amdahl.com> <13571@cbmvax.commodore.com> <d4eQ02U2010201@JUTS.ccc. Reply-To: ked01@JUTS.ccc.amdahl.com (Kim DeVaughn) Organization: Amdahl Corporation, Sunnyvale, CA 94086 Lines: 57