Hello,
I am almost sure that unclean shutdowns happen in those systems. We have tried 
to reproduce removing power each 5 minutes and the filesystem wasn't 
suffering corruption. Perhaps it's related, but I don't know.

I have talked about 'Datalogging patches' because it's the only thing 
different from our system. I have searched a lot and  few people have 
corruption with reiserfs standalone... so, it may be datalogging patches.

what do you need from reiserfsck? I guess the output of 'reiserfsck --check 
device' of perhaps you need the output of reiserfsck --rebuild tree.


Regards,

Paco




On Thursday, 13 de July de 2006 16:34, Vladimir V. Saveliev wrote:
> Hello
>
> On Wed, 2006-07-12 at 08:16 +0200, Francisco Javier Cabello wrote:
> > Hello,
> > My company develops video recorder system. Basically we work with linux
> > boxes running kernel 2.4.25. The system captures analogue video,  and
> > after processing and compressing, digital video is stored to hard disk.
> > We are recording continuously (24x7).
> >
> > We have realized that more or less a 10% of our systems are suffering
> > data corruption in the reiserfs partition.
>
> Did unclean shutdowns take place on those systems?
> If you let us see what does reiserfsck report in those cases that could
> help to understand what is is happening.
>
> > Sometimes it's possible to fix it
> > running 'reiserfsck --rebuild-tree' but not always.
> > More information:
> > -Kernel 2.4.25 + v4l2 patches
> > -Reiserfsprogs 3.6.19
> > -Datalogging patches.
> > (http://mirror.mcs.anl.gov/suse-people/mason/patches/data-logging/2.4.25/
> >)
> >
> > I have checked datalogging patches from Reiserfs website and they seem
> > equal to suse ones.
> >
> > I don't have any idea of what it's happening. The disk bandwidth is not
> > so high (300-500kb/sec). The disk is always full at 90% (we have a
> > process deleting old video).
> >
> > I have been thinking about removing Dataloggin patches but I would like
> > to have serious reason. It's not easy to check that the problem is solved
> > because we are not able to reproduce the error in our headquarter.
> >
> > Regards,
> >
> > Paco

-- 
One of my most productive days was throwing away 1000 lines of code (Ken 
Thompson)
-----------------
PGP fingerprint: AF69 62B4 97EB F5BB 2C60  B802 568A E122 BBBE 5820
PGP Key available at http://pgp.mit.edu
-----------------

Attachment: pgpfV4LKp9khT.pgp
Description: PGP signature

Reply via email to