On Mon, 25 Mar 2002, Seth Mos wrote:
> At 14:10 25-3-2002 +0200, Ivan Ivanov wrote:
> >Are there any chances for solving this problem.
> >I have read all the faq and the XFS white paper.
> >I have tried allmost all XFS patches from oss.sgi.com for various kernels
> >and know that XFS logs only metadata updates.
> >It is fast, has EA and ACL but when the system crashes for any reason most
> >of the open files ( including opened ro ) are lost - for example
> Bizarre, normally only files that have been written within 30 seconds
> before the crash could be affected, can you give some more details about
> the problem.
> What kernel are you on?
> What compiler did you use?
> Can you describe your hardware?
> Is it the machine that crashes or the power that fails?
> If you see a panic or a oops can you parse it through ksymoops and send it
> to the list?
> Every program has two purposes one for which
> it was written and another for which it wasn't
> I use the last kind.
I started testing XFS from kernel 2.4.6, the last was 2.4.18.
Compiler is gcc-2.95-3 / Slackware-8.0
Old machine - AMD K6, VIA TX Pro, WD Caviar UDMA HDD, 160 MB SDRAM.
I have no any hardware problems. Machine doesn't crashes - I am unpluging
power for testing. No kernel oops or somthing else.
The main problem is not that data writen in last 30 sec. is lost - it is
normal. The BIG PROBLEM is that entire file is lost. In the case with
XF86Config I unpluged power during X startup. XF86Config must be opened ro
but after rebooting it was garbage. Most of config files of X apps are
broken ( in my case DFM configs ) if power crashes in a X session. Any
file opened for editing with mcedit or any editor that rewrites file on save is
filled with NULL.
Mounting filesystem with -o sync has no efect.
This never hapens with ext3 in ordered data mode.
So, is it a bug or a feature of XFS jornaling filesystem.