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/ -Eric > Regards, > > Jan de Kruijf. > > > Her are the details of the installation: > > root@jan:~# xfs_info -V > xfs_info version 3.1.7 > > root@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@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@jan:~# uname -a > Linux jan 3.2.0-4-amd64 #1 SMP Debian 3.2.57-3+deb7u2 x86_64 GNU/Linux > > > _______________________________________________ > xfs mailing list > xfs@xxxxxxxxxxx > http://oss.sgi.com/mailman/listinfo/xfs > _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
