CF card for boot and binaries?
Hi. Hope I'm posting to the right place!
I am a hardware newbie. I'm intending however to set up a Mini ITX
system providing backup (rsync), netatalk and samba filesharing and lpr
facilities, and possibly some network routing.
The intention is to keep all static or mostly static data on a CF card
to keep the system stable and usable, while siting backup data and
fileshare data on a hard drive. I would like to be able to boot the
system and log into it even if the hard drive fails.
I have purchased a 512MB CF card which will be inserted into an IDE to
CF adapter. The system will also have an 80GB laptop 4200 rpm hard disk.
I am familiar with installing Debian on a variety of PPC and Intel/AMD
boxes. However I'm after some advice on how best to install the system,
and how to configure the running system. I am concious that it is unwise
to make too many writes to a CF card.
Initial thoughts are to do a minimal netinstall of Debian, simply
mounting everything except /home on the CF card. I would set the system
to remount /var and /tmp on tmpfs and then restart the daemons noted
above so that they write their logs etc to the tmpfs.
(I wonder if the approach outlined in the DeveloperWorks article would
work -- see http://www-106.ibm.com/developerworks/library/l-fs3.html --
for instance issuing "mount tmpfs /tmp -t tmpfs -o size=64m" means that
all new writes will go to tmpfs instead of the (still existing) proper
/tmp device.)
I am worried about doing this for the whole of var, however. Not only
could spool files for the printer devices not be lost unnecessarily
after an unexpected restart, but the Berkeley DB data required for the
netatalk shares (Apple file sharing) need to be kept in sync with the
shares in /home. Can I use the "mountpoint stack" method for tmpfs
filesystems for /var subdirectories -- say /var/mail specifically?
I aim to rsync the stuff in /var/log and possibly other places to a
space on home on shutdown.
Thoughts, comments and advice gratefully received!
Thanks,
Rory
--
Rory Campbell-Lange
<rory@campbell-lange.net>
<www.campbell-lange.net>
Reply to: