Filesystem and files getting corrupted
I'm working on an embedded project based on var-som-am35 from TI. [1] I experiencing a lot of corruption from files and even the entire filesystem... is there any guide on how debug filesystems corruption? We already tryied vfat and ext3 fs.. changed media, changed machines... The filesystem runs on mmc card, or on usb flash drive... There is a java aplication running on top of this filesystem, which uses JMS, that is very I/O agressive.. Cheers,
I'm really newbie and I don't know if this may help at all, but I googled "corruption of the file system debug" and found http://linux.die.net/man/8/debugfs Maybe you can give it a try if you haven't already, María.
On Tue, 25 Jun 2013 12:28:15 +0200, meccomaria@gmail.com said:
I'm really newbie and I don't know if this may help at all, but I googled "corruption of the file system debug" and found http://linux.die.net/man/8/debugfs
That won't help you debug a filesystem - debugfs is *itself* a pseudo-filesystem that allows kernel programmers to import/export large amounts of debugging info from the kernel - it was created because there are some restrictions in the procfs (for /proc) and sysfs (for /sys) filesystems that make them not very useful for bulk data. Most distros mount debugfs at /sys/kernel/debug - so everything under that is handled by debugfs rather than sysfs. For Daniel's original question:
We already tryied vfat and ext3 fs.. changed media, changed machines... The filesystem runs on mmc card, or on usb flash drive...
This tends to indicate that the problem is *not* a filesystem issue - you're just *noticing* corruption of your filesystem by some *other* kernel code. I'd rebuild the kernel, and turn on every kernel debugging option related to memory management you can find under the 'Kernel Hacking' menu. In particular, you want CONFIG_DEBUG_SLAB and also CONFIG_DEBUG_STACKOVERFLOW. Also, many kernel subsystems have debugging code for themselves, you may want to turn on as many of them as you can. Also, Manish Katiyar <mkatiyar@gmail.com> had some good suggestions to help narrow down the problem.
On Mon, Jun 24, 2013 at 1:08 PM, Daniel Hilst Selli <danielhilst@gmail.com> wrote:
I'm working on an embedded project based on var-som-am35 from TI. [1]
I experiencing a lot of corruption from files and even the entire filesystem... is there any guide on how debug filesystems corruption?
We already tryied vfat and ext3 fs.. changed media, changed machines...
If both the filesystems are getting corrupted, there is a high chance that it doesn't have to do anything with filesystem per se. There may be some random module which is corrupting incore memory/structures, and debugging that doesn't involve knowing filesystems specifics. To find the culprit, you may have to identify the interesting things related to corruption and narrow it down. Some things that can help are :- a) Is the corruption always happening at some particular offset of page or on some specific filesystem metadata b) What does the corruption look like, do structures get zeroed or get filled with some value ? If its some particular address you can try gdb watchpoints c) What is the size of corruption. How much garbage is there. Answering this will give you some hint about the structure which is overwriting
The filesystem runs on mmc card, or on usb flash drive... There is a java aplication running on top of this filesystem, which uses JMS, that is very I/O agressive..
Cheers,
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
-- Thanks - Manish
any kernel debugging always start with dmesg output, please provide a snapshot of that. (preferably posting full listing at pastebin.com). On Tue, Jun 25, 2013 at 4:08 AM, Daniel Hilst Selli <danielhilst@gmail.com>wrote:
I'm working on an embedded project based on var-som-am35 from TI. [1]
I experiencing a lot of corruption from files and even the entire filesystem... is there any guide on how debug filesystems corruption?
We already tryied vfat and ext3 fs.. changed media, changed machines... The filesystem runs on mmc card, or on usb flash drive... There is a java aplication running on top of this filesystem, which uses JMS, that is very I/O agressive..
Cheers,
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
-- Regards, Peter Teoh
On 07/04/2013 12:24 AM, Peter Teoh wrote:
any kernel debugging always start with dmesg output, please provide a snapshot of that. (preferably posting full listing at pastebin.com <http://pastebin.com>).
On Tue, Jun 25, 2013 at 4:08 AM, Daniel Hilst Selli <danielhilst@gmail.com <mailto:danielhilst@gmail.com>> wrote:
I'm working on an embedded project based on var-som-am35 from TI. [1]
I experiencing a lot of corruption from files and even the entire filesystem... is there any guide on how debug filesystems corruption?
We already tryied vfat and ext3 fs.. changed media, changed machines... The filesystem runs on mmc card, or on usb flash drive... There is a java aplication running on top of this filesystem, which uses JMS, that is very I/O agressive..
Cheers,
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org <mailto:Kernelnewbies@kernelnewbies.org> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
-- Regards, Peter Teoh Was a hardware problem... dmesg won't show anything .. We know that the file get corrupted because why try to exctract the jar file and get an error like (not a valid zip/jar file)..
Since we use SoMs, we test the same module(the little board) on another hardware (the official development kit) and it works without problems. Since is not broken, but out of specification.. it works for some time then starts to do bad things... I enabled mmc debug, got a lot of output but no error.. bad CRC or something like that.. I think that configuration (since is for embedded system) is too silent.. Thanks Cheers!
participants (5)
-
Daniel Hilst Selli -
Manish Katiyar -
María Soler Heredia -
Peter Teoh -
Valdis.Kletnieks＠vt.edu