* 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
* 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
* [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 15:31 [9fans] KFS magic size? anothy
-- strict thread matches above, loose matches on Subject: below --
2002-08-10 20:54 Geoff Collyer
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).