Hi, AU A!
Trying to kill the keyboard, [EMAIL PROTECTED] produced:
> Yea, I'm a nut with IDE, 10 drives on this box, makes for good irc pissing
> contests.
Well, talk about IRQ latency, especially if you serve a couple
of other boxes. :-)
> You like repeat answers, don't you :-)
I am just thinking at times. :-) Can't stop it then. Which shrink
do you recommend? :-)
> remote tape. I use dd to split the files, seeing as afio knows nothing about
> the vtbl and i like to update it before I swap tapes...
Hmmm ... dd does not know about vtbl either, you could change it
by hand/script though, after dd finished. However, there seems
to be -H, which could probably be used to write the vtbl if one
desires to automate it.
> I can even give u this tape script and modified ftmt (shows space in BYTES
> guys, M/K/G is VERY silly and annoying), if you really really wanna see it.
M/K/G is a bit more human readable, though, so just make it
an option.
> > No. You see, it does not matter how you install them, if by
> > hand or by some other program, they get written and deleted.
> I know that... let me explain something... I still got a.out bins, 'nuff
> said :-)
Yes, and? :-)
I know there's QMAGIC and ZMAGIC but it was new to me the magic
changed the way ext2 works ... :->
> > There are people who (have to[1]) use loadlin. Loadlin won't
> > mind, since it (and the kernel) lives on a DOS partition.
> True, but doing it that way is kinda silly, if not stupid IMHO.
Nah, you can break lilo a bit too easy for my taste, e.g. by
defragmenting the disk or moving the kernel. Loadlin just
laughs about that ... and it's a nice thing that you can kick
out DOS just like *snip*. Wish I could do that with Linux
(to run another Linux kernel, of course).
> Personally i have no use/need for dos/doze/etc... i haven't touched that
> "OS" (if you can call it that)
You can, actually, it's a (Quick and) Dirty Operation System,
unlike some GUIs we know. Doesn't mean it's very good, though.
> > Also note that e2defrag is an experimental program, it could
> > burn and destroy your partition.
> Also note that I know the author of it personally, along with alot of the
> kernel hackers... I chat with them daily... I too am a kernel hacker, but I
> have stayed out of 2.1.x for political reasons, and lack of time.
See, *you* know what e2defrag can do to your HD if you strike
bad luck, yet you offer it as a good and *safe* solution. Now,
the quality of the solution can be debated and probably measured.
But if you frag your HD trying to make it run a backup, you end
up with no bootable Linux and no HD.
> I'm busy building linux-only hardware.... THAT EVEN WORKS! :-)
Hey, I am not against Linux. I merely know people who are unable
to run a mac or Windows on their own. :-/ But I happen to have
and like some legacy games in DOS and had no time to play with
dosemu yet. (Especially as that *can* do harmful things to the
continued uptime of your Linux.)
> > [1] Try initialising a AWE32 which has only a port assigned via
> > jumpers, but gets the DMA, IRQ and so on via a dos proggy.
> I don't use that pnp crap. it's jumpers, or nothing. :-)
Hey, that card is OLD and predates my Linux time. (now, do I
date myself here? :-)
> > It's also a good test if you can recover from desaster, but a
> > bit close if you find out you can't.
> Very true... I am always prepared, however, even with different
> motherboards, etc... I have all the bases covered, including redundent
> tapes. You can never be to carefull.
You have redundant tapes, good. You store them off-site too
(or don't you?) Now, what about redundant, compatible tape
streamers? :-)
And again you say that's a *safe* thing to do, without mentioning
that you need belts, braces, airbag and 3 parachutes to be safe!
If you want to inflict pain on users, play with Win-users,
but spare the UNIXen one for a while :->
[copy FS to FS]
> Not if it's a 4g partition... and you got only one other disk that is 6g...
> it takes way to long to dd it or cat it...
So what's wrong with afio? (Yes, afio IS faster. I happened
to test that. Especially on a not 95% full FS).
[My partitions]
> Okay, that may be fine for you... but not for me...
> mainly because i need/like lots of room, so I simply mount dirs in entire
> disks :-)
Ok, then make them complete HDs. I am but a single user on an
28.8k modem (and still have some unallocated space on the HD).
> I think the "problem" is that I do compile all my own stuff...
> including libs, gcc and X... Stuff works faster and has less bloat that way,
> you know.
I do, in fact, know. But if you did your compiling on a partition
which only holds temporary data the fragmentation will only happen
there. Then you move the result to your root or user FS ...
> > [2] I could probably get away with 20 MB, or even with 15. But /
> Nope, no can do. I can't possibly do it considering i got ~5 kernel trees.
... while /usr/src should have it's own partition as well (maybe
the same you compile stuff on). You CAN do with a 20 MB / ,
even if you have 5 completely different kernels with completely
different libs and modules. Either you happento have 5 of them
(no problem since you calculate in GBs) and see that you change
the lib paths in /usr on boot, or you simply wipe root and
resurrect it from an afio file.
Yes, you *can* do that. No, it's not a preferred method for
normal operation. In fact, this is only useful for me winning
my argument and a few funny special circumstances.
> and loads of sources. Believe me, you woulld be in shock if you saw all the
> stuff I work on here. It's amazing that I have time to talk to people.
You need a direct neural connection to your 'puters, it seems.
And a loudspeaker on the 'puter. ;-)
> RPM? no no... dude, I hand compile all my stuff, no dists here.
> Source tarballs forever!
> I don't like depending on organizations/teams for precompiled stuff, that
> can sometimes be non streamlined, or buggy, or compiled wrong.
Now, I don't have the time to hand-compile everything in sight.
I do compile some stuff, and do pack it into an RPM. Upgrading
(to my next compile) or removing the whole stuff just is much
easier. And you do get source RPMs too.
> I'm not the only user, and, I feed 10 boxes from this one. (NFS)
Just another reason to get a separate /home partition, neh?
> /var doen't change enough here to justify it.
/var always changes, and can overflow. In your case, it would
overflow /tmp as well. Ever ran a system with *no* space in /tmp?
But then, it's your system and you may damn well do with it as
you like. :-)
> I don't do news, cause it's a waste of bandwidth and time, and it also
> invites spam :-)
Just choose and match your newsgroups. Some are virtually
spam-free (and any spammer who tried would be very roasty soon).
> > [7a] Note that most of the files are shorter than one block (1k)
> Nope... I have many large multimegabyte databases here.
That applied to news. And in databases you seldom have sequential
reads, do you?
> I need GBs not MBs
Then make a whole disk your scratch/tmp partition. Or even two
or three. You are the one with the HDs, :-) though I wonder
why you don't use SCSI-Raid systems ... but then I guess you
have your reasons.
> I know this. However.... in 2.0.x cache is over agressive, and tends to
> kick out your buffers (libs). You can thank me for the tuning in 2.2, it was
> my suggestion (ranting) to sct.
I do thank you for that.
Now, one can backport the patch, can't one?
> > Hmmm ... the kernel has no need to look sequentially through
> > the library to find the relevent part ... it issuses a seek to a
> > position, then the VFS can just look in the inode, the indirect
> > and probably double indirect nodes to find the position of the
> > block(s) on the HD. The inodes should still be in the cache
> > and if not, are close to each other in the same inode block.
> Unless it's on the disk... it still eats cpu cycles anyhow :-)
But that's not the problem, since your 386 worked well, you
said, and I guess you have more spare cycles than a whole 386
can offer for backup.
> SMP in 2.0.x does have a very high latency, but it can be tuned fairly well
> via IRQtune, unfortunately you can't do this in 2.1/2.2 (or so i'm told it
> won't matter because of how APIC works) It did work (i think) in SMP tho.
> Again, I need to find time to test it.
You can't tune it on 2.0.15-18 either (experimental round-robin,
balanced priority system).
> >But does that not mean
> > that every *5th* file was not continously written, but had one
> > (or more) jump(s) in it? That should not be really bad (unless
> > you start filling up the disk).
> Ok, then explain why it works now... I'm talking not only writing, but
> reading too. BOTH had the problem before the defragmentation (a.k.a HD
> restore)
Now, you say it's not a low memory condition, but probably a
fragmented disk. You also mention buffering does not help.
You say (see below) that now another tape drive acts up and
won't work at 1000Mbit/s. Remembering that the overhead data
for the stuff is around 40% ...
... now that's strange, since even the most fragmented HD
should be able to give you that sort of throughput. It's not
the processor (I ran 2000Mbis/s on a single Pentium 150Mhz for
a long time with no errors of that kind). You have 4 times the
RAM. Yet one tape won't go at 1000 (while the other one does).
*thinks (yeah, I am sick)*
*lightbulb*
Hey, if it was really fragmentation, how do we explain that one
of them runs OK at 1000 and the other doesn't? Do you drive
them at different IRQ's on separate controlers? What happens if
you strip down the machine bit by bit until the other tape works
too? It could be anything (including bad connections), since
you opened the machine and did your stuff.
> > [9] -n means read-only, say no to everything (so it's safe).
> > zo'e loosely means 'whatever' in Lojban.
> yeah, yeah... *eye's roll* I'm not a nubie... I know however you don't
> realize/know that... please spare me in the future :-)
[snip]
> You really do think I'm clueless eh? this is getting funnier as I read on...
You may know, but does Joe Random Reader know? What's wrong
with spreading clues (it's how I learned a lot)? And how come
you speak Lojban?
> I never buy from iomega... Thier stuff is crap... can't format tapes,
> etc... totally silly...
That's the 2GB and the MAX (Pro). The 3200 and 800 can (and do).
But I would never buy a *floppy* tape drive again. :-)
> I really do think that defragmentation did help.
> Infact, I plan on fragging the friggin libs on a test box to prove it
> to myself some time on down the road... mebby... if I get time...
Ah, that's a plan. Oh, while you are on it, how about building
a complete working ftape/afio ramdisk ... if it's in a ramdisk
it won't hinder the IDE drive, and you can control the amount
of fragmentation easily.
> # load the modules
[snip]
> # this seems to be good enough for me... even tho I do have 128M ram :-)
> swapout 6
> ftmt setdrvbu 16
> swapoff -a ; swapon -a
Interesting ... you swapout AFTER ftape is loaded and you replace
'buffer' by more kernel memory buffers. But I don't understand
why you swapoff-swapon ... you just shorten the amount of RAM
you have aviable.
> [015] 0 ftape-calibr.c (ftape_calibrate) - TC for dc_wait()' 21
> nsec (at 6166 counts).
> ^^^^------ this does vari... I hope that it's not the reason...
Naah. Doubt it. By how much does it vary?
> Could it be possible that when it's initializing, and a lib (or other file)
> gets hit and reads disk... we get a wrong count? :-)
Well, probably, but I don't know ftape enough to know how much
the timing there is critical. Probably it's just a rough idea
how fast we are.
> Anything else you need to see ( except my passwords HAHAHAH )? Let me know :-)
Your SSN? :-)
-Wolfgang
--
PGP 2 welcome: Mail me, subject "send PGP-key".
Unsolicited Bulk E-Mails: *You* pay for ads you never wanted.
How to dominate the Internet/WWW/etc? Destroy the protocols! See:
http://www.opensource.org/halloween.html
