Data loss XFS with RT kernel on Debian.

[Jan de Kruyf]

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.

Regards,

Jan de Kruijf.


Her are the details of the installation:

root at jan:~# xfs_info -V
xfs_info version 3.1.7

root at jan:~# xfs_info /usr
meta-data=/dev/sda3 isize=256 agcount=4, agsize=732416 blks
              = sectsz=512 attr=2
       data = bsize=4096 blocks=2929664, imaxpct=25
               = sunit=0 swidth=0 blks
naming =version 2 bsize=4096 ascii-ci=0
log =internal bsize=4096 blocks=2560, version=2
       = sectsz=512 sunit=0 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0

This combination does not work:
root at jan:~# uname -a
Linux jan 3.14-0.bpo.1-rt-amd64 #1 SMP PREEMPT RT Debian 3.14.7-1~bpo70+1
(2014-06-21) x86_64 GNU/Linux

Also kernel 3.10-0.bpo.3-rt-amd64 does not work

But this combination works:
 root at jan:~# uname -a
Linux jan 3.2.0-4-amd64 #1 SMP Debian 3.2.57-3+deb7u2 x86_64 GNU/Linux
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://oss.sgi.com/pipermail/xfs/attachments/20140705/6a950f37/attachment.html>