[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Desktop user: Etch or the next testing?



On Fri, Apr 06, 2007 at 11:42:06AM +0800, Bob wrote:
> Douglas Allan Tutty wrote:
> >On Fri, Apr 06, 2007 at 09:39:28AM +0800, Bob wrote:

Yes writes, sorry :)
> 
> You mean no *writes* have to happen every time something is read, and 
> the faster the system can access its binaries the faster it feels (to a 
> point) as the faster things load, particularly new programs, like the 
> first time you start Open Office, if the binaries are on a fast drive 
> they load faster. An experiment I want to run is to get a 4200 rpm SATA 
> laptop drive and 10,000 RPM SATA Raptor of similar size and compare the 
> responsiveness of the same install on the same hardware on different 
> drives and then figure out what mountpoints should go on a CF card in a 
> DMA capable IDE (or SATA) adapter to achieve similar speed, my hunch is 
> I should put at least /var and /home on the harddrive and the rest on 
> the CF card.
> 

How fast do you need OO to load?

Then again, I'm a CLI person (except for some GUI frontends that make
life a little easier).  For a while, I had a box with a 171 MB drive
that only held the stuff that couldn't easily come over NFS (like /boot,
/).  Everything else came over NFS, the catch was the network was a
serial line running PPP (no NIC on the box).  I ran icewm.  Sure mozilla
took a while, but partly that's because it was a 486.  It was still
faster than running mozilla via ssh X forwarding.

> I'd like to use a ram disk fs (unionfs?) like a bootable cd where things 
> get linked back to the media and you can replace a file in the running 
> system, by replacing it in ramdisk, but then have a commit feature to 
> update the CF card.
> 
> 
> I haven't tried tmpfs, but I thought that the standard place to put ISOs 
> your building was in /tmp so if you have a DL DVDRW it should be 9GB, 
> what else is tmp used for.

I'd create a striped LV and mount it on /var/local/cache, or even
/var/cache

AFAIK, /tmp is for small tmp files things make (fifos, sockets?)  On the
other hand, mc decompresses compressed stuff there when you go to look
in it.  I also use the pam tmpdir module.

You could put the isos you're building in /var/tmp

ISO's I'm downloading (which can take a week or so) goes in ~/uldl which
is backed up separatly.

> 
> >If the system crashes because of a drive failure, and your /home is on
> >software raid1, what keeps the system crash from not crashing the
> >software raid1, and the filesystem on top of it?
> >  
> 
> Nothing other than the unlikeliness of it, I'd have thought the RAID 
> software was quite robust, certainly I've had powercuts to my file 
> server and the RAID software grumbles, does some checking and comes up, 
> then I do a consistency check of the file system (JFS on RAID5, no LVM 
> ATM, it'll be interesting when I come to add another drive) and mount as 
> usual.

I guess I'm differentiating between the whole system going down in an
instant due to power failure vs a system crashing from a drive failure.  

> 
> RAID is not a substitute for backup anyway, it's meant to be a tool to 
> increase availability by adding redundancy, in this case I could slap in 
> a new drive, do a reinstall, rebuild my RAID1 array, and I'm back up 
> without having to do all that tedious mucking about with DDS tapes (or 
> DVDRs, Rsync, Gmail, whatever you use) but even if your data is hosed 
> you can restore from backup (you *do* backup right) and your fine.

For the cost of one disk, if you put the system stuff on raid1 too,
there is not downtime other than that required to physically change the
drive.  No tedius mucking about with /etc.

Sure I back up.  Anything that apt didn't put there, I back up.  The
first place my backup sets go is /var/local/backup (protected by raid1),
the second place they go is another box via rsync.  Then they go to CD.
I don't yet have a removable hard drive.  I've looked into backup media
and it _seems_ that hard drives in a ruggedized case are more rugged
than tape, cheaper, and don't require an expensive tape drive.  

> 
> Actually I don't mean to sound quite so sanctimonious about it, my 
> backup frequency is dictated by how much it going to piss me off if I 
> loose everything science the last one, when I get the the point of 
> losing sleep over it I dig out my DDS drive and SCSI card, drop them in 
> and do a backup, (I really need a bigger box) then I sleep well for a 
> couple of months.
> 

Perhaps instead of a bigger box, you need a spare box dedicated to doing
backups.  There's supposed to be a way to backup from box A to the tape
drive attached to box B without having the backup set sit on box B's
hard drive.

Doug.




Reply to: