xfs
[Top] [All Lists]

Re: Data loss XFS with RT kernel on Debian.

To: Jan de Kruyf <jan.de.kruyf@xxxxxxxxx>, xfs@xxxxxxxxxxx
Subject: Re: Data loss XFS with RT kernel on Debian.
From: Eric Sandeen <sandeen@xxxxxxxxxxx>
Date: Sat, 05 Jul 2014 17:08:18 -0500
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <53B85AB0.30800@xxxxxxxxxxx>
References: <CAA85NCjXU7rK8C4AcQ4Tnxowx5MFBUyAoLW_nuwmKyOFL-_PgQ@xxxxxxxxxxxxxx> <53B85AB0.30800@xxxxxxxxxxx>
On 7/5/14, 3:06 PM, Eric Sandeen wrote:
> On 7/5/14, 7:41 AM, Jan de Kruyf wrote:
>> Hallo,
>>
>> While doing a reasonably high density job like rsynching a
>> subdirectory from one place to another, or tarring it to a pipe and
>> untarring it at the other end, I note that the cpu usage goes
>> practically to 100% and when I after 5 minutes or so I reset the
>> computer the writing has not finished at all. However on the stock
>> Debian kernel it works without a problem.
>> 
>> Could I still use this combination in an industrial environment
>> reading and writing reasonably short text files? So far I did not
>> experience this problem with normal day to day use. It stuck up its
>> head during installation of gnat-gpl-2014-x86_64-linux-bin from the
>> http://libre.adacore.com/download/ page. The offending code is in
>> the Makefile in the top directory page. The Xterm will give you the
>> place where it gets stuck.

> http://lwn.net/Articles/457667/

Ok, sorry - that was a little short ;)

If you have some 100% cpu livelock or whatever, that does sound like
a potential bug.  Perhaps some tracing or profiling can help figure
out what has gone wrong there.  Maybe sysrq-t & see where the active
threads are, or even top?

But if you are surprised that you lost data when you did a hard reset,
the URL above is informative.

-Eric

<Prev in Thread] Current Thread [Next in Thread>