|
|
| Author |
Message |
| 25 new of 124 responses total. |
remmers
|
|
response 9 of 124:
| 
Mar 28 17:41 UTC 1999 |
Or (on Grex, anyway) you can use du with the -b option to get bytes.
|
mcnally
|
|
response 10 of 124:
|
Mar 28 18:02 UTC 1999 |
but be aware that the total for "du -b" and "du -k" doesn't necessarily
jibe..
% du -s -k ~mcnally
45 /a/m/c/mcnally
% du -s -b ~mcnally
29208 /a/m/c/mcnally
My guess is that "du -b" just adds up the bytes in the file contents,
which is not actually an accurate way to count how much space is being
used by the files.
Files in the 4.2BSD (McKusick, et al.) filesystem being used on Grex
consume filesystem space in greater-than-1-byte increments. The
filesystem is divided into "blocks", which are themselves sub-divided
into "fragments". Depending on how the filesystem was initialized,
the smallest amount of disk space a file can consume will be one fragment
(disregarding the file's entry in a directory file, which also consumes
some space.)
That means that if Grex's filesystems are created with 4K blocks, each
consisting of 8 fragments (I don't know what the actual parameters are,
I didn't create the filesystems when they were set up..) that the smallest
amount of disk space a file can use will be 512 (= 4096 / 8) bytes(*)
So if you have a file with just a single character in it, and assuming
I am right about "du -b", then "ls -l" will report a size of 1 byte,
"du -b" will count it as a byte, and "du -k" will count it as a full
fragment -- 512(*) bytes -- a much more accurate measure of how much
space you're really using.
(*) again, assuming 512 byte fragments *only* for purposes of example.
|
mdw
|
|
response 11 of 124:
|
Mar 30 04:21 UTC 1999 |
/a and /c were built with a fragsize of 1024 and a blocksize of 8192.
|
orinoco
|
|
response 12 of 124:
|
Mar 30 21:44 UTC 1999 |
(out of curiousity, why is there no /b ?)
|
kaplan
|
|
response 13 of 124:
|
Mar 31 01:46 UTC 1999 |
There is a /b. It's the bbs shell. The bbs shell was given the shortest
possible name to save space in the password file.
|
i
|
|
response 14 of 124:
|
Mar 31 01:51 UTC 1999 |
/b is a symbolic link to /bbs/bbs.sh, which is the "real" bbs shell.
|
steve
|
|
response 15 of 124:
|
Mar 31 06:51 UTC 1999 |
Right, that was created back long before we saw that we needed
a more general way of labeling the partitions for user areas. The
current one letter system will let us have 23 more such partitions,
and hopefully we'll never go beyond that! So poor little /b is a
lagacy directory.
|
davel
|
|
response 16 of 124:
|
Mar 31 11:11 UTC 1999 |
"*lag*acy" meaning it increases system lag? 8-{)]
|
bdh1
|
|
response 17 of 124:
|
Apr 2 06:57 UTC 1999 |
Munificent Grace to ye grex abacus staff whom in one day sothe to an
conquered a dreaded Y2M monster inhabiting the sacred plane of the grex
abacus.
|
ryan
|
|
response 18 of 124:
|
Apr 2 14:08 UTC 1999 |
This response has been erased.
|
katie
|
|
response 19 of 124:
|
Apr 3 04:53 UTC 1999 |
Is there a reason I wouldn't receive a couple of e-mails that a particular
person sent me? I believe in both cases he mailed me by responding to an
e-mail I sent him. It happened over a week apart and I'm getting plenty of
e-mail from other people.
|
keesan
|
|
response 20 of 124:
|
Apr 5 15:15 UTC 1999 |
I apparently sent someone half an email yesterday (subject line was the last
thing that got sent) from a computer that we discovered shortly after had a
virus. He could check for viruses. This is a partition table virus, whatever
that means.
|
gull
|
|
response 21 of 124:
|
Apr 5 19:09 UTC 1999 |
Don't worry. Partition table virii can't be spread by email, or at least I
don't know of any that can be. And there's nowhere to stick one before the
subject line anyhow.
|
mcnally
|
|
response 22 of 124:
|
Apr 6 06:24 UTC 1999 |
partition table viruses?
|
keesan
|
|
response 23 of 124:
|
Apr 6 19:16 UTC 1999 |
I was suggesting that the friend who had trouble sending email might have a
problem at his end. (See the item on viruses for a detailed description of
our virus problem.) And that he should check his computer for viruses. A
virus may have been responsible for an intermittent formatting problem on the
computer that our virus spread from.
Partition table viruses can definitely spread by floppy disk and by
nullmodem cable. Anyone know about tape backup? If so, please offer us some
help in the computer virus item (66, I think it is). We would like to know
how to remove the virus from the hard disk, since repartitioning and
reformatting did not remove it.
|
mcnally
|
|
response 24 of 124:
|
Apr 7 04:53 UTC 1999 |
(would someone please explain to me what good it would do to put
a virus in the partition table? are you, perhaps, talking about
*boot sector* viruses?)
|
keesan
|
|
response 25 of 124:
|
Apr 7 15:36 UTC 1999 |
sdscan called it a partition table virus. It also infects the boot sector
of a floppy disk. It does spread by tape, too. Anti exe virus is what sdscan
calls it.
|
prp
|
|
response 26 of 124:
|
Apr 7 19:09 UTC 1999 |
re 24: On a hard disk the partition table is in the boot record.
Or rather the first boot record. There is one per disk plus one
per partition.
|
mcnally
|
|
response 27 of 124:
|
Apr 8 00:59 UTC 1999 |
re #26: I still don't understand what good it'd do putting virus code
in the partition table. It's not like the partition table is
executed the way the boot loader is.. If, by "partition table
virus" people mean a virus that overwrites the partition table
with stuff (virus code, garbage, or anything else..) then I
guess I understand the point of that (though it's a nasty thing
to do..) but it doesn't sound like that's what Cindi's talking about.
|
keesan
|
|
response 28 of 124:
|
Apr 8 04:25 UTC 1999 |
It hides there and attacks exe com and dll files. It is gone now, Kent fixed
it. Now Netscape often runs, but at 120 bytes per seco or less, as low as
30.
What has hit grex since midnight? Very slow.
|
mcnally
|
|
response 29 of 124:
|
Apr 8 06:41 UTC 1999 |
<sigh>
|
gull
|
|
response 30 of 124:
|
Apr 8 20:46 UTC 1999 |
Re #27: I'd guess that'd be the case. Bear in mind most people have no
clue about how their hard disks are *really* laid out.
|
keesan
|
|
response 31 of 124:
|
Apr 8 21:16 UTC 1999 |
Was there a grex problem from 12 to 12:20 or so this morning? If not, we have
some other phone or modem or computer problem. Please let me know. Our two
Netscape computers were running at as low as 68 bytes/sec and grex was waiting
10-15 seconds to display a word.
|
steve
|
|
response 32 of 124:
|
Apr 8 21:55 UTC 1999 |
Around 12:06am, Grex gets VERY busy for a bit, doing a bunch of nightly
things. There have been a few occaisons when I thought Grex was under
attack, it was so slow. This is something we should work on optimizing;
the work needs to be done, but hopefully we can alter the schedule such
that there isn't an emmense queue of things to do all at the same time.
|
keesan
|
|
response 33 of 124:
|
Apr 9 13:58 UTC 1999 |
What happens and where at 12:06? India is 10 1/2 hours different.
|
