bug#35587: sort order wrt lower/upper case
I'd expect "B" being the first line here: echo a B c d | xargs -n 1 | sort using sys-apps/coreutils-8.30 at a stable hardened Gentoo Linux, but it is "a". Is this a bug or a feature? (origin use case was "lsmod | sort" where now the head line of lsmod isn't any longer the first line of the output. -- Toralf PGP C4EACDDE 0076E94E
bug#20578: du counts a multiple times bind-mounted directory just for the first listed directory in a directory lists
I created few chroot image, each conteaining a Gentoo Linux minimal image.
I do bind-mount a directory from the host (~35 GB of downloaded package files)
onto a directory of each of the chroots to save space and bandwith.
A "du -ms" however counts that value just for the first listed directories:
tor-relay /mnt/qa/tinderbox # du -ms amd64-hardened-stable_*
amd64-hardened-unstable_* 2>/dev/null
42318 amd64-hardened-stable_20150513-221439
11948 amd64-hardened-unstable_20150513-215830
tor-relay /mnt/qa/tinderbox # du -ms amd64-hardened-unstable_*
amd64-hardened-stable_* 2>/dev/null
48790 amd64-hardened-unstable_20150513-215830
5434amd64-hardened-stable_20150513-221439
Pls Cc:- me - I'm not subscribed
tor-relay /mnt/qa/tinderbox # eix -I sys-apps/coreutils
[I] sys-apps/coreutils
Available versions: 8.20 8.21 ~8.22 ~8.22-r1 ~8.23 {acl caps gmp
multicall nls selinux static vanilla xattr USERLAND="BSD"}
Installed versions: 8.21(11:34:15 AM 10/25/2014)(acl nls xattr -caps -gmp
-selinux -static -vanilla USERLAND="-BSD")
Homepage:http://www.gnu.org/software/coreutils/
Description: Standard GNU file utilities (chmod, cp, dd, dir,
ls...), text utilities (sort, tr, head, wc..), and shell utilities (whoami,
who,...)
--
Toralf
pgp key: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 0076 E94E
--
"; the past is all dirty and cruel in the modern popular imagination, with the
exception of the Romans, who are just cruel"
Ian Mortimer, 2008, "The Time Traveller's Guide to Medieval England"
bug#9394: Fwd: Re: bug#9394: coreutils-8.7 - few test cases failed
Toralf Förster wrote at 12:57:39 > Jim Meyering wrote at 11:49:26 > > > It's been two weeks. > > Sry for the delay - I went on holiday in Istanbul ;-) > > > Are there any test failures with *unmodified* coreutils-8.13 on your > > system? > > No. > Therefore I should file a bug against Gentoo's dev, or ? > > -- > MfG/Sincerely > Toralf Förster > pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3 -- MfG/Sincerely Toralf Förster pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3
Re: factor is too fast
At Monday 27 April 2009 08:35:11 Mike Frysinger wrote : > On Tuesday 21 April 2009 08:19:23 Philip Rowlands wrote: > > On Tue, 21 Apr 2009, Toralf F?rster wrote: > > > For a long time I used the command "factor" to test my system WRT the > > > cpu ondemand governor of the linux kernel, eg for issues like this : > > > http://bugzilla.kernel.org/show_bug.cgi?id=12385 > > > > > > However switching from coreutils-6.10 to 7.1 (stable Gentoo Linux) now > > > the factor command is too fast: it takes only 0.003 sec instead of 5.5 > > > sec for the same prime number. > > > > That's probably due to this entry from NEWS: > > > > * Noteworthy changes in release 7.0 (2008-10-05) [beta] > > > >If the GNU MP library is available at configure time, factor and > >expr support arbitrarily large numbers. Pollard's rho algorithm is > >used to factor large numbers. > > if GMP is too fast, then you could try building coreutils with USE=gmp. if > coreutils itself got a new algo, then i guess save the old binary ... > -mike Thx, I like this speed improvement in general - and this was really impressive - and b/c I was pointed to the command timeout BTW this has the advantage that I do not have to wait 3x longer (600 MHz versus 1700 MZh) to realize that the ondemand governor doesn't work :-) -- MfG/Sincerely Toralf Förster pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3 ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
factor is too fast
For a long time I used the command "factor" to test my system WRT the cpu ondemand governor of the linux kernel, eg for issues like this : http://bugzilla.kernel.org/show_bug.cgi?id=12385 However switching from coreutils-6.10 to 7.1 (stable Gentoo Linux) now the factor command is too fast: it takes only 0.003 sec instead of 5.5 sec for the same prime number. Therefore I'm wondering whether you have a hint for me which number I could use nowadays ? :-) Thx -- MfG/Sincerely Toralf Förster pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3 ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
coreutils-5.2.1 : df show negative number for an cifs - mounted dir
Hello,
for an cifs mounted directory with > 1 TB capacity I got from df under this
Gentoo Linux system:
[EMAIL PROTECTED] ~ $ uname -a
Linux n22 2.6.15 #7 Fri Jan 20 09:45:58 CET 2006 i686 Intel(R) Pentium(R) M
processor 1700MHz GenuineIntel GNU/Linux
the output:
[EMAIL PROTECTED] ~ $ df -m /mnt/GSA/
Filesystem 1M-blocks Used Available Use% Mounted on
//ehngsa.ibm.com/ 2192704 -18014398509001472 2673216 101% /mnt/GSA
:-(
The mount options are :
[EMAIL PROTECTED] ~ $ mount | grep GSA
//ehngsa.ibm.com/ on /mnt/GSA type cifs (rw,mand,noexec,nosuid,nodev)
Here is the strace log:
[EMAIL PROTECTED] ~ $ strace df -m /mnt/GSA/
execve("/usr/bin/df", ["df", "-m", "/mnt/GSA/"], [/* 62 vars */]) = 0
uname({sys="Linux", node="n22", ...}) = 0
brk(0) = 0x8051000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or
directory)
open("/etc/ld.so.cache", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=86969, ...}) = 0
mmap2(NULL, 86969, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7f53000
close(3)= 0
open("/lib/libc.so.6", O_RDONLY)= 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\20V\1\000"..., 512) =
512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1199648, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb7f52000
mmap2(NULL, 1146164, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0xb7e3a000
mmap2(0xb7f4c000, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|
MAP_DENYWRITE, 3, 0x111) = 0xb7f4c000
mmap2(0xb7f5, 7476, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|
MAP_ANONYMOUS, -1, 0) = 0xb7f5
close(3)= 0
mprotect(0xb7f4c000, 4096, PROT_READ) = 0
mprotect(0xb7f7f000, 4096, PROT_READ) = 0
munmap(0xb7f53000, 86969) = 0
open("/dev/urandom", O_RDONLY) = 3
read(3, "\242~\214\206", 4) = 4
close(3)= 0
open("/usr/lib/locale/locale-archive", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No
such file or directory)
brk(0) = 0x8051000
brk(0x8072000) = 0x8072000
open("/usr/share/locale/locale.alias", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=2586, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb7f68000
read(3, "# Locale name alias data base.\n#"..., 4096) = 2586
read(3, "", 4096) = 0
close(3)= 0
munmap(0xb7f68000, 4096)= 0
open("/usr/lib/locale/[EMAIL PROTECTED]/LC_CTYPE", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=208004, ...}) = 0
mmap2(NULL, 208004, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7e07000
close(3)= 0
stat64("/mnt/GSA/", {st_mode=S_IFDIR|0777, st_size=0, ...}) = 0
open("/etc/mtab", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=473, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb7e06000
read(3, "/dev/hda9 / ext3 rw,noatime 0 0\n"..., 4096) = 473
read(3, "", 4096) = 0
close(3)= 0
munmap(0xb7e06000, 4096)= 0
fstat64(1, {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 2), ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb7e06000
write(1, "Filesystem 1M-blocks "..., 67Filesystem
1M-blocks Used Available Use% Mounted on
) = 67
lstat64("/mnt", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat64("/mnt/GSA", {st_mode=S_IFDIR|0777, st_size=0, ...}) = 0
stat64("/mnt/GSA", {st_mode=S_IFDIR|0777, st_size=0, ...}) = 0
statfs64("/mnt/GSA", 84, {f_type=0xff534d42, f_bsize=1024,
f_blocks=2245328896, f_bfree=2737373184, f_bavail=2737373184, f_files=0,
f_ffree=0, f_fsid={0, 0}, f_namelen=4096, f_frsize=1024}) = 0
write(1, "//ehngsa.ibm.com/ 2192704 -"..., 74//ehngsa.ibm.com/
2192704 -18014398509001472 2673216 101% /mnt/GSA
) = 74
munmap(0xb7e06000, 4096)= 0
exit_group(0) = ?
--
MfG/Regards
Toralf Förster
pgpVaXZfgmG1f.pgp
Description: PGP signature
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Fwd: Re: df shows wrong size for smbfs/cifs/nfs/davfs mounted directories
Hi Bob,
"-e statfs" gave no output whereas "-e statfs64" prints some information. If
this is waht you want, here are the results. If you want, I can send you the
whole output - or greped for "stat".
BTW The nfs-problem went away switching from 2.6.12-gentoo-r10 kernel to the
new 2.6.13 kernel-gentoo-r3. Now I get a "time out"
Ok, here are the results:
DAV:
n22 # df -m /mnt/ramdisk/dav/ /mnt/dav_n22/
Filesystem 1M-blocks Used Available Use% Mounted on
tmpfs 660 1 660 1% /mnt/ramdisk
http://n22/[EMAIL PROTECTED]/
8790 0 8790 0% /mnt/dav_n22
n22 # strace -e statfs64 df -m /mnt/ramdisk/dav/ /mnt/dav_n22/
statfs64("/mnt/ramdisk", 84, {f_type=0x1021994, f_bsize=4096, f_blocks=168960,
f_bfree=168956, f_bavail=168956, f_files=129449, f_ffree=129441, f_fsid={0,
0}, f_namelen=255, f_frsize=4096}) = 0
statfs64("/mnt/dav_n22", 84, {f_type="CODA_SUPER_MAGIC", f_bsize=1024,
f_blocks=900, f_bfree=900, f_bavail=900, f_files=900,
f_ffree=900, f_fsid={0, 0}, f_namelen=255, f_frsize=1024}) = 0
NFS-server n22_tun is up and running:
n22_uml ~ # df /mnt/nfs/n22_tmp
Filesystem 1K-blocks Used Available Use% Mounted on
n22_tun:/tmp 14011712 10641536 2658400 81% /mnt/nfs/n22_tmp
n22_uml ~ # strace -e statfs64 df /mnt/nfs/n22_tmp
Filesystem 1K-blocks Used Available Use% Mounted on
statfs64("/mnt/nfs/n22_tmp", 84, {f_type="NFS_SUPER_MAGIC", f_bsize=32768,
f_blocks=437866, f_bfree=105318, f_bavail=83075, f_files=1782368,
f_ffree=1254493, f_fsid={0, 0}, f_namelen=255, f_frsize=32768}) = 0
n22_tun:/tmp 14011712 10641536 2658400 81% /mnt/nfs/n22_tmp
NFS-server n22_tun was stopped:
n22_uml ~ # df /mnt/nfs/n22_tmp
Filesystem 1K-blocks Used Available Use% Mounted on
n22_tun:/tmp 77371252437321868667518976 0
77371252437321868667518976 0% /mnt/nfs/n22_tmp
n22_uml ~ # strace -e statfs64 df /mnt/nfs/n22_tmp
Filesystem 1K-blocks Used Available Use% Mounted on
statfs64("/mnt/nfs/n22_tmp", 84, {f_type="NFS_SUPER_MAGIC",
f_bsize=4294967295, f_blocks=4294967295, f_bfree=4294967295,
f_bavail=4294967295, f_files=0, f_ffree=0, f_fsid={0, 0}, f_namelen=0,
f_frsize=4294967295}) = 0
n22_tun:/tmp 77371252437321868667518976 0
77371252437321868667518976 0% /mnt/nfs/n22_tmp
-- Weitergeleitete Nachricht --
Subject: Re: df shows wrong size for smbfs/cifs/nfs/davfs mounted directories
Date: Samstag 08 Oktober 2005 19:52
From: Bob Proulx <[EMAIL PROTECTED]>
To: Toralf Förster <[EMAIL PROTECTED]>
Cc: bug-coreutils@gnu.org
Toralf Förster wrote:
> I am wondering about the displayed free disk space:
> n22 ~ # df -m /mnt/ramdisk/dav/ /mnt/dav/
> Filesystem 1M-blocks Used Available Use% Mounted on
> tmpfs 660 1 660 1% /mnt/ramdisk
> http://n22/davfs/ 8790 0 8790 0% /mnt/dav
>
> Why there seems to be ~8,8 GB space free whereas the whole ramdisk has only
> 660 MB ?
Thanks for the report. Please run the experiment again using strace
to find the result of the statfs(2) calls made by the program to the
kernel.
strace -e statfs df -m /mnt/ramdisk/dav/ /mnt/dav/
This will report what information the df command is getting and
therefore will explain why df is printing what it is printing.
> normal behaviour (n22_uml is the UML sytem, n22_tun the host) :
> n22_uml ~ # df /mnt/nfs/n22_tmp
> Filesystem 1K-blocks Used Available Use% Mounted on
> n22_tun:/tmp 14011712 10646784 2653184 81% /mnt/nfs/n22_tmp
>
> Now I stop nfs at n22_tun:
> n22 ~ # /etc/init.d/nfs stop
> ...
> Ang got finally under UML:
> n22_uml ~ # df /mnt/nfs/n22_tmp
> Filesystem 1K-blocks Used Available Use% Mounted on
> n22_tun:/tmp 77371252437321868667518976 0
> 77371252437321868667518976 0% /mnt/nfs/n22_tmp
Please do the same thing here too.
strace -e statfs df /mnt/nfs/n22_tmp
> Here the exports - file from the host:
> n22 ~ # cat /etc/exports
> # /etc/exports: NFS file systems being exported. See exports(5).
> /tmpn22_uml(rw,sync,all_squash)
Looks fine to me.
> and the appropriate fstab - entry under UML:
> n22_uml ~ # grep n22_tmp /etc/fstab
> n22_tun:/tmp/mnt/nfs/n22_tmpnfs soft 0 0
I recommend to avoid the soft option for nfs mounts. It can lead to
silent data corruption. But I don't think it is related to your
current problem.
Bob
--
df shows wrong size for smbfs/cifs/nfs/davfs mounted directories
I filed in the past several bugs regarding df and different file systems into several bugzilla's - every time with respect to the file system but it seems that df itself is the root cause. Here are the issues: DAVFS: I have created a DAV Filesystem on my machine n22 into the ramdisk, I can access succesfully the DAV repository via cadaver or via mount.davfs2. My ramdisk has 660 MB, the DAV is defined in the apache config file as: ... Alias /davfs /mnt/ramdisk/dav/fs ... I am wondering about the displayed free disk space: n22 ~ # df -m /mnt/ramdisk/dav/ /mnt/dav/ Filesystem 1M-blocks Used Available Use% Mounted on tmpfs 660 1 660 1% /mnt/ramdisk http://n22/davfs/ 8790 0 8790 0% /mnt/dav Why there seems to be ~8,8 GB space free whereas the whole ramdisk has only 660 MB ? NFS: Mounting a nfs dir under UML with option soft and stopping nfs - service at the host system, shows wrong block size, eg: normal behaviour (n22_uml is the UML sytem, n22_tun the host) : n22_uml ~ # df /mnt/nfs/n22_tmp Filesystem 1K-blocks Used Available Use% Mounted on n22_tun:/tmp 14011712 10646784 2653184 81% /mnt/nfs/n22_tmp Now I stop nfs at n22_tun: n22 ~ # /etc/init.d/nfs stop * Stopping NFS mountd ... [ ok ] * Stopping NFS daemon ... [ ok ] * Unexporting NFS directories ... [ ok ] * Stopping NFS statd ... Ang got finally under UML: n22_uml ~ # df /mnt/nfs/n22_tmp Filesystem 1K-blocks Used Available Use% Mounted on n22_tun:/tmp 77371252437321868667518976 0 77371252437321868667518976 0% /mnt/nfs/n22_tmp Here the exports - file from the host: n22 ~ # cat /etc/exports # /etc/exports: NFS file systems being exported. See exports(5). /tmpn22_uml(rw,sync,all_squash) and the appropriate fstab - entry under UML: n22_uml ~ # grep n22_tmp /etc/fstab n22_tun:/tmp/mnt/nfs/n22_tmpnfs soft 0 0 SMBFS/CIFS: Here the results for a file system mounted as smbfs: [EMAIL PROTECTED] ~/workspace/misc $ df /mnt/GSA/ Filesystem 1K-blocks Used Available Use% Mounted on //foo.bar/660653296 -73786976293836709276 1662150484 101% /mnt/GSA [EMAIL PROTECTED] ~/workspace/misc $ df -m /mnt/GSA/ Filesystem 1M-blocks Used Available Use% Mounted on //foo.bar/ 645170 -72057594036949912 1623194 101% /mnt/GSA And now the same directory re-mounted as cifs: [EMAIL PROTECTED] ~/workspace/misc $ df /mnt/GSA/ Filesystem 1K-blocks Used Available Use% Mounted on //foo.bar/660733952 -18446744072707932160 1662353408 101% /mnt/GSA [EMAIL PROTECTED] ~/workspace/misc $ df -m /mnt/GSA/ Filesystem 1M-blocks Used Available Use% Mounted on //foo.bar/ 645248 -18014398508503872 1623360 101% /mnt/GSA Both have wrong negative results, but they differs in addition,too ! -- MfG/Regards Toralf pgpPSkTGMY6Ok.pgp Description: PGP signature ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
