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.
