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
>
|