9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
* Re: [9fans] KFS magic size?
@ 2002-08-10 20:54 Geoff Collyer
  0 siblings, 0 replies; 3+ messages in thread
From: Geoff Collyer @ 2002-08-10 20:54 UTC (permalink / raw)
  To: 9fans

To elaborate on anothy's note, here's a summary of the situation that
I wrote a few years ago:

The maximum size of a single file in a kfs (or plan 9 file server)
file system is determined by the file system block size (there are
single and double indirect blocks but no triples).  The maximum size
is approximately (blocksize/512)⁳*8 megabytes or, more accurately,
(6+x+x⁲)*d bytes, where d=blocksize-8 and x=d/4:

blksize	max. file size in MB	in bytes
512	7.69			8068032
1024	62.76			65812416
1536	213.20			223564736
2048	507.02			531656640
2560	992.22			1040419776
3072	1716.79			1800185792
3584	2728.73			2861286336
4096	4076.05			4274053056

In addition, at the time of writing (April 1999), the file server and
kfs use 32-bit integers internally to hold file sizes and offsets and
some of those integers are signed, so the practical limit on the size
of a single file is 2⁳ⁱ-1 bytes (roughly 2GB).



^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [9fans] KFS magic size?
@ 2002-08-10 15:31 anothy
  0 siblings, 0 replies; 3+ messages in thread
From: anothy @ 2002-08-10 15:31 UTC (permalink / raw)
  To: 9fans

the design of kfs is such that the maximum file size is
derived from the block size. i believe the following are
correct for finding the max size from a given block size:
	max_in_blocks = 6 + iba + iba*iba
	iba = (blocksize - 8)/sizeof(ulong)
multiply by (blocksize -8) to get size in bytes.
so the simplest way to answer your question is "use a
bigger block size" (which, of course, involves reformating
your kfs partition, and makes it a bit less efficient with
space).

my solution to this problem, since i wasn't willing to
reformat my existing partition, was to simply buy enough
ram to hold a CD image.
ア


^ permalink raw reply	[flat|nested] 3+ messages in thread

* [9fans] KFS magic size?
@ 2002-08-10 10:44 Lucio De Re
  0 siblings, 0 replies; 3+ messages in thread
From: Lucio De Re @ 2002-08-10 10:44 UTC (permalink / raw)
  To: 9fans mailing list

There seems to be an odd limit on file size with KFS.  This is what
it looks like:

	% dd -if /dev/zero -of zeroes -bs 1048576 -count 100
	dnodebuf: trip indirect
	write: file system full
	63+0 records in
	63+0 records out
	%

I picked this up while trying to build a 9660 image for a more
recent copy of the Plan 9 distribution and whereas the above occurred
under 3rd Edition Plan 9, my original attempts were foiled by a
4th Edition installation of KFS.  Curiously, disk/mk9660 crashed
and left an image 65816576 bytes in size, whereas the above dd and
an attempt at cp'ing the 9660 image to another file both produced
files of size 65814528, 2048 bytes fewer.  I must confess at this
point that I'm not entirely certain of the "cp" file size, but the
"dd" number did ring a bell.

The other oddity is that I did produce a 9660 image on a previous
occasion, although I don't recall the circumstances, so I must have
tickled a KFS problem in some fashion I hadn't done before.  What
comes to mind is the possibility that I may have used a bigger
block size, although I'm sure I'm using the same disks I had
configured previously.

My immediate requirement would be to create the image so I can dump
it to CD-RW (thanks for the wonderful interface!), but I'm very
curious about the cause of the problem and how to obviate it in
future.

++L


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2002-08-10 20:54 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-08-10 20:54 [9fans] KFS magic size? Geoff Collyer
  -- strict thread matches above, loose matches on Subject: below --
2002-08-10 15:31 anothy
2002-08-10 10:44 Lucio De Re

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).