I'm always nervous about pulling the plug on a system... could cause file corruption in that act alone if a write is in progress.
My local friendly RadioShack has a special on SanDisk Ultra II 2GB CF cards, $19.99. 2GB seams a bit overkill but so what, I got one and am about to start the process of loading it up. I'll also redirect syslog to ram (or maybe another server I have here) and I'm going to take a look inside the asterisk gui and see if I can get it to use a temp location other than its source directory... /var/spool/asterisk/tmp would seam appropriate. Crossing fingers for a more stable system! Thanks, David On Thu, Jan 1, 2009 at 11:50 PM, Darrick Hartman <dhart...@djhsolutions.com>wrote: > David, > > I had this happen with one box over the summer. There were some other > (let's call them environmental) issues that caused the on-site personnel to > think they could solve the problem by pulling the plug on the system. Most > file system problems should be resolved by fsck automatically on reboot. If > the automatic check doesn't resolve the problems (like it's not able to do > in your case) the file system must be severely damaged. > > You have TOTAL control over both CDR and syslogs. If you look at the > /etc/init.d/asterisk file, the cdr files are only stored on the keydisk or > unionfs partition if /mnt/kd/cdr-csv or /mnt/kd/cdr-custom exist. If > neither exist, all data is written to a tmpfs ramdisk. > > Similarly, if PERSISTLOG is not set to yes, then all syslog data is sent to > a ramdisk. > > I have no control of the behavior of the asterisk-gui. We only included it > since several people have requested it's inclusion. It has improved. > > Based on your statement that you're using a cheap compact flash card, I > would say that a majority of your problems are the card itself and not > unionfs or any other mechanism. Some compact flash cards are just plain > JUNK! I've been happy with Transcend and SanDisk. Soekris recommends ONLY > using SanDisk. Some of the cheaper CF cards don't properly implement all of > the functions that these other cards do. Using one of these other cards is > very risky! Even the Transcend cards don't properly support the > cable-select feature required to have the Soekris net5501 boards call the CF > card as /dev/hda. (most of the Transcend cards show up as /dev/hdb). > > I have several systems running 0.6 builds (0.6.2 and later) on net5501 or > VIA targets with none of these same problems. I'm using systems that have > as little as 128MB of ram (my home office system) and a new 8 port Digium > analog card up to a net5501 with 8 analog lines (plus a few others with SIP > only). > > If there is a problem, we certainly want to determine the cause. Please > switch to a SanDisk card and see if the problems persist. If you can't get > a SanDisk card. See if you can get a Transcend or a Silicon Systems card. > Wim has some of these at www.kd85.com Silicon Systems has a license from > SanDisk for some of their technology for wear leveling and other features. > > http://www.siliconsystems.com/pdf/SiliconDriveCF.pdf > > Specifically look at the wear leveling sections of that document. > > Darrick > > > David Kerr wrote: > >> I've been having major stability issues over the last week with my alix >> box and 0.6 build. I have tracked it down to disk corruption taking place >> on the CF card in the asturw partition. Things seem to be exasperated by >> constant updates to the flash card from CDR and syslogs, etc that we've been >> discussing in another thread. Here is an example of today's heartache... >> >> On booting... >> >> Configuring for unionfs... >> Checking asturw filesystem >> ext2fs_check_if_mount: No such file or directory while determining whether >> /dev/ >> hda2 is mounted. >> >> >> ASTURW: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY. >> (i.e., without -a or -p options) >> Fsck detected errors on /dev/hda2 (4) >> /bin/sh: can't access tty; job control turned off >> # >> >> Then on removing the CF card and attaching to my CentOS box to diagnose... >> >> [r...@localhost ~]# fsck /dev/sdb2 >> fsck 1.39 (29-May-2006) >> e2fsck 1.39 (29-May-2006) >> ASTURW contains a file system with errors, check forced. >> Pass 1: Checking inodes, blocks, and sizes >> Extended attribute block 131557 has reference count 35, should be 33. >> Fix<y>? yes >> >> Pass 2: Checking directory structure >> Entry 'sysinfo_output71.html' in /stat/var/lib/asterisk/static-http/config >> (61833) has deleted/unused inode 61838. Clear<y>? yes >> >> Pass 3: Checking directory connectivity >> Pass 4: Checking reference counts >> Pass 5: Checking group summary information >> Block bitmap differences: -149504 >> Fix<y>? yes >> >> Free blocks count wrong for group #4 (32269, counted=32270). >> Fix<y>? yes >> >> Free blocks count wrong (211504, counted=211505). >> Fix<y>? yes >> >> Inode bitmap differences: -61838 >> Fix<y>? yes >> >> Free inodes count wrong for group #4 (15442, counted=15443). >> Fix<y>? yes >> >> Free inodes count wrong (107849, counted=107850). >> Fix<y>? yes >> >> >> ASTURW: ***** FILE SYSTEM WAS MODIFIED ***** >> ASTURW: 342/108192 files (0.6% non-contiguous), 4711/216216 blocks >> [r...@localhost ~]# >> >> After running fsck and placing the CF card back into the alix box, I boot >> again OK and everything seems fine. But as the system has locked up on me >> (no calls, no internet access, cannot ssh in) a few times recently I'm >> getting worried. >> >> All I can think of is that my CF card is going bad. It's a cheap Adata 1GB >> and I have two of them both of which are exhibiting the problem. What would >> be a more robust card? >> >> Thanks >> David >> > > >
------------------------------------------------------------------------------
_______________________________________________ Astlinux-users mailing list Astlinux-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/astlinux-users Donations to support AstLinux are graciously accepted via PayPal to pay...@krisk.org.
