[osol-discuss] pax considered harmful
Hello,
can anyone confirm my observations with the attached test script?
pax corrupts files if they contain more than 57 holes in it.
I just found out today by accident after copying a large backup file. I was
able to reproduce the bug on Solaris 10 and snv133, on UFS and ZFS.
Is pax in the closed bins? I couldn't find its source code.
Daniel
#!/bin/perl -w
use Fcntl;
use Fcntl 'SEEK_CUR';
# 57 = Ok
# 58 = Error
$count = 58;
$file = testfile-$count;
$cpdir = n;
$holesize = 2**20;
$rand = 2**16;
sysopen(F, $file, O_RDWR|O_CREAT|O_TRUNC) or die sysopen: $!;
foreach (1..$count)
{
$o = $holesize + rand($rand);
sysseek(F, $o, SEEK_CUR);
syswrite(F, the quick brown fox jumps over the lazy dog);
}
close(F);
-d $cpdir or mkdir($cpdir, 0777);
system(pax -rw $file $cpdir);
system(md5sum $file);
system(md5sum $cpdir/$file);
unlink $file;
unlink $cpdir/$file;
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
Re: [osol-discuss] pax considered harmful
Am 13.06.10 15:08, schrieb Volker A. Brandt: Daniel Rock writes: Hello, can anyone confirm my observations with the attached test script? pax corrupts files if they contain more than 57 holes in it. shelob:/tmp/test,8483 uname -a SunOS shelob 5.10 Generic_141414-02 sun4v sparc SUNW,Sun-Fire-T1000 shelob:/tmp/test,8484 ./paxtest.pl ffbcc5af1a2923652b9d72fe2800ff21 testfile-58 ffbcc5af1a2923652b9d72fe2800ff21 n/testfile-58 13.62u 1.96s 0:15.65 99.6% Could you increase the number of holes in the perl script to some real large value like 1024 or even higher? On x86 (Solaris 10 and snv133) the ok/error limit was 57/58. Maybe the limit is higher on SPARC? Daniel ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] pax considered harmful
Am 13.06.2010 16:25, schrieb Volker A. Brandt: shelob:/tmp/test,8496 foreach f ( 128 256 512 1024 2048 4096 ) Do you test on tmpfs? Could you please re-run the tests on UFS or ZFS? I will revive my old SPARC machine and rerun the tests myself on SPARC. But I first have to patch it (first time I switched the machine on since October 2007). When I truss the pax process I see the SEEK_HOLE|SEEK_DATA lseek(): llseek(4, 0, SEEK_DATA) = 1048576 llseek(4, 0, SEEK_HOLE) = 0 llseek(4, 0, SEEK_DATA) = 1048576 llseek(4, 1048576, SEEK_HOLE) = 1179648 llseek(4, 1179648, SEEK_DATA) = 2097152 llseek(4, 2097152, SEEK_HOLE) = 2228224 llseek(4, 2228224, SEEK_DATA) = 3145728 llseek(4, 3145728, SEEK_HOLE) = 3276800 llseek(4, 3276800, SEEK_DATA) = 4194304 [and so on] But then, when it comes to write the output file, pax seems to forget the first holes: llseek(4, 0x105E, SEEK_DATA)= 0x106C llseek(4, 0x106C, SEEK_HOLE)= 0x106CA777 llseek(4, 0x106CA777, SEEK_DATA)Err#6 ENXIO llseek(4, 0, SEEK_SET) = 0 fpathconf(4, 21)= 512 llseek(4, 0x0A8C, SEEK_SET) = 0x0A8C llseek(6, 0x0A8C, SEEK_SET) = 0x0A8C fstat64(6, 0x08046FD0) = 0 brk(0x0809F9A0) = 0 brk(0x080BF9A0) = 0 read(4, \0\0\0\0\0\0\0\0\0\0\0\0.., 131072) = 131072 write(6, \0\0\0\0\0\0\0\0\0\0\0\0.., 131072) = 131072 llseek(4, 0x0A9E, SEEK_SET) = 0x0A9E llseek(6, 0x0A9E, SEEK_SET) = 0x0A9E fstat64(6, 0x08046FD0) = 0 Daniel ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] pax considered harmful
Am 13.06.2010 15:08, schrieb Volker A. Brandt: Daniel Rock writes: Hello, can anyone confirm my observations with the attached test script? pax corrupts files if they contain more than 57 holes in it. shelob:/tmp/test,8483 uname -a SunOS shelob 5.10 Generic_141414-02 sun4v sparc SUNW,Sun-Fire-T1000 It seems you don't have patch 138623-02 installed. I reactivated my SPARC machine, updated the kernel patch up to 137137-09 (it is a slow Blade 150) and installed the pax patch above. With this pax patch my test program failed exactly with the same count value (57 ok, 58 error) as on x86. Daniel ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] X hangs on snv130
Hello, after upgrading to snv130 (from snv129) X hangs on startup. The Xorg process seems stuck. The kernel prints messages like: WARNING: GPU hang detected try to reset ... wait for irq_queue seqno 2, now seqno 1 WARNING: drm_irq_install: irq already enabled WARNING: GPU hang detected try to reset ... wait for irq_queue seqno 2, now seqno 1 WARNING: drm_irq_install: irq already enabled When killing Xorg (have to kill it with SIGKILL) the kernel finally prints out: WARNING: hardware wedged Copying back drm + i915 kernel modules from snv129 helped for me to make X work again. Daniel ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] X hangs on snv130
Am 25.12.2009 17:50, schrieb Malte Hahlbeck: I've got the same problem, but I don't know where to find the neccassary files. Could you help please? You need to replace the kernel modules /kernel/misc/drm /kernel/drv/i915 for 32 bit kernels, and /kernel/misc/amd64/drm /kernel/misc/amd64/i915 for 64 bit kernels. Daniel ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] How to delete files as dos 'del *.java /s' on command line
Alexander Eremin schrieb:
On Wed, 2009-09-09 at 05:18 -0700, Davide wrote:
How can I delete files recursively in all subdirectories with .java extension?
Under ms-dos I used to execute this: 'del *.java /s'
I tried 'rm -rf *.java', on command line, but it didn't work,
it simply shows me the newer command line with a ready cursor.
Thanks in advance for any precious answer!
# cd YOUR_DIR
# find . -name *.java|xargs rm -rf
find DIRECTORY -type f -name '*.java' -exec rm {} +
Make sure you put quotes around the pattern you are searching, so that
the shell doesn't accidently expand wildcards with files found in the
current directory.
xargs isn't safe for filenames with whitespace characters in it.
You probably also don't want to delete directories, just plain files.
Daniel
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
Re: [osol-discuss] In Unix
Raja schrieb: Hi, Good Morning..!!! how will get the below lines, from Strat to End in between lines, i want to write in seprate file. #Start of lines added by SUNWscu 20 4 * * 0 /usr/cluster/lib/sc/newcleventlog /var/cluster/logs/eventlog 20 4 * * 0 /usr/cluster/lib/sc/newcleventlog /var/cluster/logs/DS # End of lines added by SUNWscu how can do this in using grep -A 2 filename or awk give me the solution This is a generic shell/scripting question: crontab -l | sed -n -e '/Start.*SUNWcsu/,/End.*SUNWcsu/p' Daniel ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Hotplugging sata drives
Joerg Schilling schrieb: So the sata driver seems to be OK at low level. There is however no new device in /devices/. Is this a known issue? I don't know if it is intended that way. But after plugging the SATA disk I searched for a connected but unconfigured port with cfgadm -l then enabled that port with cfgadm -c configure sataX/Y Daniel ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Sun to make Solaris more Linux like
[EMAIL PROTECTED] schrieb: It probably shouldn't be the default, but I can't really tell what this means: 131996712968156 9652530272 1% quick, how much space is that? Enough free. With the -h option the width of the filesystem size is roughly the same - regardless if the filesystem is 1kB or 1TB. So I have to actually *read* the output instead of a quick look how wide the size column is. That only helps upto about 6-8 digits, if that. The problem is the formatting. In Solaris df/ls the size column has a fixed width. For larger sizes the output gets distorted: -rwsr-s--x 1 oracle dba 133894000 Mai 29 2006 oracle* -rwxr-xr-x 1 oracle dba 1339524 Mai 19 2006 oratclsh* -rwxr-xr-x 1 oracle dba 48 Sep 25 2000 oraxml* -rwxr-xr-x 1 oracle dba 48 Sep 25 2000 oraxsl* -rwxr-xr-x 1 oracle dba 10636376 Mai 29 2006 proc* FreeBSD's utilities in contrast check for the largest required width and adjusts output accordingly: -rwsr-s--x 1 oracle dba 133894000 Mai 29 2006 oracle* -rwxr-xr-x 1 oracle dba1339524 Mai 19 2006 oratclsh* -rwxr-xr-x 1 oracle dba 48 Sep 25 2000 oraxml* -rwxr-xr-x 1 oracle dba 48 Sep 25 2000 oraxsl* -rwxr-xr-x 1 oracle dba 10636376 Mai 29 2006 proc* So even If you don't see the absolute numbers you quickly realize that oracle is two magnitudes larger than oratclsh. If df had a similar output, I'd prefer this: 83886083041200 534740837% 335544321605719 31794110 5% 62914560 37766679 1412994873% 62914560 11017932 1412994844% 1535901696 1187247048 26307973582% 134217728 32200480 7472805031% 41943041392793 280151134% over this any time: 8.0G 2.9G 5.1G37% 32G 1.5G30G 5% 60G36G13G73% 60G11G13G44% 1.4T 1.1T 251G82% 128G31G71G31% 4.0G 1.3G 2.7G34% I don't count digits. I just memorize patterns. More digits = larger size. Daniel ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Sun to make Solaris more Linux like
[EMAIL PROTECTED] schrieb: FreeBSD's utilities in contrast check for the largest required width and adjusts output accordingly: -rwsr-s--x 1 oracle dba 133894000 Mai 29 2006 oracle* -rwxr-xr-x 1 oracle dba1339524 Mai 19 2006 oratclsh* -rwxr-xr-x 1 oracle dba 48 Sep 25 2000 oraxml* -rwxr-xr-x 1 oracle dba 48 Sep 25 2000 oraxsl* -rwxr-xr-x 1 oracle dba 10636376 Mai 29 2006 proc* There's this thing with cut which makes such output problematic. Why? In the example above with cut (and absolute columns) you also end up in the wrong column if the file size is large enough (10MB and larger). Daniel ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Sun to make Solaris more Linux like
Hugh McIntyre schrieb: You can use (n)awk in the case above. For example, what happens with cut in the case above if a future project allows usernames 8 characters? But granted that some people will have scripts that use cut, so it's hard to change. Compatible formatting if stdout is not a terminal. Optimized formatting if stdout is a terminal. Daniel ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Sun to make Solaris more Linux like
Shawn Walker schrieb: On 19/05/07, Daniel Rock [EMAIL PROTECTED] wrote: Compatible formatting if stdout is not a terminal. Optimized formatting if stdout is a terminal. Which would be really annoying to me as a user. I would go to look at the output, think I'll just pipe that to such and such command and then wonder why my parsing wasn't working... So how many scripts of yours failed in the past? % df -k [...] /usr/lib/libc/libc_hwcap2.so.1 12395698 7271171 500057160%/lib/libc.so.1 (output wrapped in two lines) % df -k | cat [...] /usr/lib/libc/libc_hwcap2.so.1 12395698 7271171 5000571 60% /lib/libc.so.1 (output in a single line) % ls /var adm cronldapnewsrun statmon apache dmi lib nfs sadmsvc [...] (multiple columns) % ls /var | cat adm apache apache2 appserver [...] (single column) etc. etc. You really shouldn't cut output by column number but by field number. And please don't forget to set LC_ALL=C in your scripts. I have seen lots of scripts which couldn't interpret the real size of verfügbar disk space while trying to parse a df -k output. Daniel ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Sun to make Solaris more Linux like
Shawn Walker schrieb: As I said before, the point is that it is unexpected behaviour. Do you count the number of columns in an interactive context? Unless the man page for the utility explicitly lists the behaviour in question, it is undesireable in my view. Even then, I have misgivings about it. It is current practise in lots of utilities without a notice in a man page. So no difference to the sitiation today. You also assume that I keep scripts around. I don't. So what is your point? Daniel ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Sun to make Solaris more Linux like
Doug Scott schrieb: The patch for df.c below checks to see if stdout is a tty (i.e. interactive), and will add the -h option if no other options conflict. If stdout is not a tty (i.e. a script), the df command is unchanged. Is there anything wrong with this idea?? Why does everyone like the -h output? I personally hate it - and would hate it even more if it would be the default. With the -h option the width of the filesystem size is roughly the same - regardless if the filesystem is 1kB or 1TB. So I have to actually *read* the output instead of a quick look how wide the size column is. In order to compensate for larger disks and larger filesystem sizes I'd would much more like to see a -m flag (for the output in MBytes instead of kBytes). With then only 7 digits (instead of 10) even a filesystem of ~1TB could be easily checked. Daniel ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Kconfig in Solaris?
man -s 7 Intro Daniel ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Kconfig in Solaris?
man -s 7 Intro Daniel ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: x86 vs SPARC
Gino Ruopolo schrieb: Galvin Maltby wrote: That's never been my experience. Not my experience neither. Also other sysadmin I know found the same when switched from Sparc to Opteron... Then you know the wrong sysadmins. Simple test: Compile some files in parallel (dmake -j X) on a 2 cpu box: (1) dmake -j 2 real 1:18.18 user 1:37.05 sys18.57 Load average: 1.32 (2) dmake -j 8 real 1:12.24 user 1:37.65 sys18.42 Load average: 4.32 (3) dmake -j 64 real 1:14.06 user 1:37.90 sys18.49 Load average: 11.86 . Same system time . only a slight increase in user time from -j 8 to -j 64 I also did some other tests with an Oracle database and also achieved nearly no additional overhead, regardless if 2 or 32 sessions were working on the database. Daniel ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Re: LAMP for Solaris aka SAMP
UNIX admin schrieb: Long story short: -xO5 is only good in tandem with a feedback profile, otherwise chances are high that the code will end up being bigger and slower. Short answer: The -xO5 code was faster than the -xO3 code even without profiling data. Short answer supplement: Performance tests on different architectures should have comparable optimization flags to make them meaningful. In my first benchmark run there was a discrepancy which I corrected. Daniel ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: LAMP for Solaris aka SAMP
Patrick Mauritz schrieb: the biggest advantage of x86-64 over x86 is that it has a bunch registers more. so code tends to end up being more compact and faster in 64bit mode than in 32bit mode on x86. Faster: Yes, x86-64 is most of the time faster than ia32 code. Smaller: Usually no. Some examples: $ size /kernel/genunix /kernel/amd64/genunix /kernel/genunix: 1097477 + 40705 + 184544 = 1322726 /kernel/amd64/genunix: 1629491 + 53808 + 284888 = 1968187 $ size /usr/sfw/lib/libcrypto.so /usr/sfw/lib/amd64/libcrypto.so /usr/sfw/lib/libcrypto.so: 944748 + 84582 + 8310 = 1037640 /usr/sfw/lib/amd64/libcrypto.so: 1237360 + 123896 + 10540 = 1371796 So x86-64 code is usually ~30% larger than ia32 code. This could also have a negative effect on performance on some benchmarks (negative cache effects). I tried a simple benchmark (openssl speed) compiled with Sun Studio 11: 32 bit: compiler: cc -KPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -fast -O -Xa available timing options: TIMES TIMEB HZ=1000 [sysconf value] timing function used: times The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes md21355.59k 2862.13k 3971.95k 4391.52k 4536.13k mdc2 0.00 0.00 0.00 0.00 0.00 md4 14415.52k49963.59k 147409.25k 287259.35k 398234.25k md5 11809.87k39453.73k 109647.76k 197091.34k 257964.24k hmac(md5) 15609.16k48985.32k 127089.03k 210243.13k 260602.33k sha1 13064.55k42881.78k 109946.85k 180015.07k 221802.32k rmd16010302.32k29856.92k67258.51k97641.59k 112474.32k rc4 94902.10k 104165.04k 108189.22k 109169.61k 109425.24k des cbc 36492.43k38349.58k38847.14k38664.25k39016.97k des ede3 14029.63k14316.70k14404.98k14249.21k14405.30k idea cbc 39330.38k41825.71k42741.53k42785.97k42911.13k rc2 cbc 21974.04k22727.73k22935.10k22958.94k22988.77k rc5-32/12 cbc 0.00 0.00 0.00 0.00 0.00 blowfish cbc 66036.54k72483.74k74132.32k74722.80k74838.59k cast cbc 41895.25k44178.37k44798.45k45101.02k45219.29k aes-128 cbc 39793.82k43434.97k44639.73k44914.96k44925.55k aes-192 cbc 34567.00k37394.44k38244.70k38494.36k38628.45k aes-256 cbc 31409.13k32771.61k33463.78k33622.82k33709.01k sha25611090.84k27899.81k54231.09k71305.92k78475.95k sha512 3701.83k14766.45k24035.07k34668.49k39845.03k signverifysign/s verify/s rsa 512 bits 0.001101s 0.75s908.2 13369.4 rsa 1024 bits 0.004872s 0.000206s205.3 4853.2 rsa 2048 bits 0.026451s 0.000624s 37.8 1602.9 rsa 4096 bits 0.156266s 0.002043s 6.4489.5 signverifysign/s verify/s dsa 512 bits 0.000786s 0.000937s 1271.6 1067.4 dsa 1024 bits 0.002128s 0.002564s469.9390.1 dsa 2048 bits 0.006429s 0.007673s155.5130.3 64 bit: compiler: cc -KPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -fast -xarch=amd64 -xstrconst -Xa -DL_ENDIAN available timing options: TIMES TIMEB HZ=1000 [sysconf value] timing function used: times The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes md21659.88k 3489.66k 4827.13k 5362.44k 5509.88k mdc2 0.00 0.00 0.00 0.00 0.00 md4 18718.17k60346.24k 153484.15k 249352.42k 305693.55k md5 15092.03k46804.15k 113282.40k 175620.12k 209357.83k hmac(md5) 17113.37k51404.40k 120048.88k 179077.59k 210206.45k sha1 14774.09k42463.94k76415.66k 120985.27k 146305.33k rmd16011647.51k31071.76k61971.67k82660.30k91280.71k rc4 169194.41k 183235.03k 185723.58k 187306.07k 188022.50k des cbc 38621.38k39945.91k40263.18k40329.16k40383.68k des ede3 15407.90k15598.96k15654.06k15672.38k15675.24k idea cbc 43711.29k46672.59k47439.44k47668.87k47704.25k rc2 cbc 23168.34k23851.05k24037.38k24081.51k24055.92k rc5-32/12 cbc 0.00 0.00 0.00 0.00 0.00 blowfish cbc 65418.92k70249.71k71613.96k71999.04k72241.55k cast cbc 43763.67k45880.14k46417.32k46572.90k46605.58k aes-128 cbc 87854.71k96515.10k99639.62k 100672.92k 101320.07k aes-192 cbc 78534.91k85301.65k87745.73k88271.48k88410.94k aes-256 cbc 70460.15k76202.03k78129.60k78656.47k78688.77k sha256 9523.14k22442.72k40073.15k
Re: [osol-discuss] Re: LAMP for Solaris aka SAMP
Frank Hofmann schrieb: You're comparing a bit apples and oranges there with the compiler options you used. 32 bit: compiler: cc [...] -fast -O -fast implies -xtarget=native which implies -xchip=native the -O after -fast shouldn't negate the -xchip=XXX selection. Daniel ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: LAMP for Solaris aka SAMP
Joerg Schilling schrieb:
64 Bit code on Sparc is typically 5-10% slower, AMD64 code is typically 30%
faster because there are twice as much registers.
30% is very optimistic. My test results vary between 30% slower and 200%
faster depending on the application and compiler. On average I'd say AMD64
code will be ~10% faster.
My previous posted results with openssl speed are void. 32 bit code was
compiled with -xO3 while the 64 bit code was compiled with -xO5. I reran the
tests which on average still favour 64 bit code - but to a lesser extent.
Test environment:
cc: Sun C 5.8 Patch 121016-03 2006/06/07
ube: Sun Compiler Common 11 Patch 120759-08 2006/08/08
../gcc-4.1.1/configure --with-system-zlib --with-gnu-as
--with-as=/usr/sfw/bin/gas --without-included-gettext
--without-libiconv-prefix --enable-languages=c,c++,ada,fortran,objc --with-x
--enable-java-awt=xlib
Thread-Modell: posix
gcc-Version 4.1.1
AMD Athlon(tm) 64 X2 Dual Core Processor 4400+ ( == Opteron 175)
2x1 GB RAM Dual Channel DDR400 CL3 ECC
Numbers below are relative performance AMD64 vs. IA32 (0 IA32 faster, 0%
AMD64 faster)
(1) OpenSSL 0.9.8d
Studio 11 32 vs. 64 bits
./Configure no-asm solaris-x86-cc
./Configure no-asm solaris64-x86_64-cc
cc -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -fast
-xstrconst [ -xarch=amd64 -Xa -DL_ENDIAN ]
type16B 64B 256B1024B 8192B
md2 -10.05% -11.15% -11.74% -12.12% -12.34%
md4 8.86% 6.05% 0.52% -5.88% -10.08%
md5 16.38% 10.94% 0.72% -8.88% -14.06%
hmac(md5)-2.63% -5.14% -8.79% -12.78% -14.68%
sha1 4.24% -11.21% -21.91% -26.25% -28.58%
rmd160 -1.22% -10.99% -20.55% -26.60% -29.35%
rc4 78.52% 82.69% 80.98% 81.75% 81.79%
des cbc -8.77% -9.57% -9.63% -9.69% -9.63%
idea cbc 6.43% 6.04% 6.02% 6.10% 5.85%
rc2 cbc -0.68% -1.16% -1.18% -1.27% -1.46%
blowfish cbc -7.59% -9.09% -9.35% -9.42% -9.98%
cast cbc-23.04% -24.26% -24.59% -25.31% -24.85%
aes-128 cbc 60.48% 61.71% 61.91% 62.32% 62.27%
aes-192 cbc 64.41% 63.91% 64.31% 65.11% 65.13%
aes-256 cbc 65.03% 66.60% 67.89% 67.40% 67.45%
sha256 -16.11% -19.27% -23.42% -25.54% -26.56%
sha512 82.83% 83.21% 112.24% 129.11% 137.42%
signverify
rsa 512 bits 40.73% 28.55%
rsa 1024 bits28.89% 17.55%
rsa 2048 bits15.93% 3.47%
rsa 4096 bits 7.69% -3.87%
dsa 512 bits 29.38% 30.25%
dsa 1024 bits20.51% 21.10%
dsa 2048 bits 7.06% 7.65%
gcc 4.1.1 32 vs. 64 bits
./Configure no-asm solaris-x86-gcc
./Configure no-asm solaris64-x86_64-gcc
gcc -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -O3
-fomit-frame-pointer -DL_ENDIAN
{ -march=pentium -DOPENSSL_NO_INLINE_ASM |
-m64 -DL_ENDIAN -DMD32_REG_T=int }
type16B 64B 256B1024B 8192B
md2 -7.40% -9.46% -10.21% -9.36% -8.95%
md4 26.77% 24.25% 19.80% 14.47% 11.19%
md5 18.20% 16.72% 11.50% 6.06% 2.69%
hmac(md5)19.03% 16.02% 10.69% 5.95% 2.59%
sha1 16.22% 13.13% 16.53% 20.12% 22.24%
rmd160 24.41% 17.51% 12.67% 8.13% 6.07%
rc4 22.65% 22.98% 23.10% 23.19% 23.17%
des cbc 38.35% 37.66% 37.36% 37.29% 37.11%
idea cbc 10.96% 6.71% 3.94% 3.69% 3.33%
rc2 cbc 1.53% 0.27% -0.23% -0.22% -0.33%
blowfish cbc 1.14% -1.38% -1.93% -2.16% -2.19%
cast cbc 95.12% 97.09% 97.57% 97.94% 98.07%
aes-128 cbc 76.22% 82.13% 83.89% 84.50% 84.79%
aes-192 cbc 84.24% 86.69% 88.12% 88.91% 89.08%
aes-256 cbc 83.59% 90.55% 91.96% 92.34% 92.52%
sha256 -3.48% -2.75% -1.07% -0.29% 0.09%
sha512 177.33% 177.60% 242.40% 279.34% 301.04%
signverify
rsa 512 bits 94.92% 109.87%
rsa 1024 bits 124.20% 123.21%
rsa 2048 bits 136.36% 130.01%
rsa 4096 bits 142.86% 129.65%
dsa 512 bits117.52% 114.45%
dsa 1024 bits 137.08% 128.02%
dsa 2048 bits 134.24% 130.59%
(2) gzip/bzip2
I did also measure compression/decompression speed with gzip and bzip2 (test
file: gcc-4.1.1.tar):
Studio 11 32 vs. 64gcc 4.1.1 32 vs. 64
gzip -5.78 % 23.69 %
gunzip2 2.46 % 2.26 %
bzip2 3.47 %
Re: [osol-discuss] kstat information
Louwtjie Burger schrieb: bash-3.00$ kstat -m unix -n vminfo module: unixinstance: 0 name: vminfo class:vm crtime 47.129589548 freemem 232290532919 snaptime2847958.77893493 swap_alloc 45084054035 swap_avail 952763588224 swap_free 957527836045 swap_resv 49848301856 If I use pagesize and the 'pages' to calculate, I cannot get close to swap -s output. These values will be updated (added up) each seconds, so they will only provide you an average since reboot - not terribly useful, therefor I use: struct anoninfo ai; swapctl(SC_AINFO, ai); See: http://cvs.opensolaris.org/source/xref/on/usr/src/uts/common/os/clock.c#920 vs. http://cvs.opensolaris.org/source/xref/on/usr/src/uts/common/vm/vm_swap.c#476 Daniel ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] EOVERFLOW on 'cat /proc/pid/status'
Thomas Maier-Komor schrieb: Hi, can anybody explain to me, what the reason for this might be? Please take a look at the following: [EMAIL PROTECTED]:/proc/700$ uname -a SunOS azalin 5.10 Generic_118833-22 sun4u sparc SUNW,Sun-Blade-2500 [EMAIL PROTECTED]:/proc/700$ ps -ef|grep 700 root 700 1 0 22:16:03 ? 0:00 /usr/sfw/sbin/snmpd root 1289 1253 0 23:40:50 pts/7 0:00 grep 700 [EMAIL PROTECTED]:/proc/700$ ls -l status -r 1 root root1232 Sep 15 22:16 status [EMAIL PROTECTED]:/proc/700$ cat status cat: input error on status: Value too large for defined data type [EMAIL PROTECTED]:/proc/700$ cat /proc/$$/status [garbage] /proc structures of 64 bit processes must be accessed by 64 bit programs. /usr/sfw/bin/snmpd is a 64 bit program: % file /usr/sfw/sbin/snmpd snmpd: ELF 64-Bit MSB ausführbar SPARCV9 Version 1, über dynamischen Link verknüpft, nicht entfernt Daniel ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] IDE driver attach to pseudo RAID-Controller
Daniel Rock schrieb: Hi, I try to install Solaris on a new machine. This machine contains an IDE controller with some Host-RAID controller - besides that you normally can still access the controller as a plain old IDE controller. PCI class 01-04-00 (Mass storage RAID controller) instead of PCI class 01-01-00 (Mass storage IDE controller) I have patched the pci_autoconfig kernel module, so that it also accepts pciclass,0104 as a valid PCI IDE driver. http://cvs.opensolaris.org/source/xref/on/usr/src/uts/i86pc/io/pci/pci_boot.c#is_pciide With this modification the system boots and is able to see at least one of the two disks attached to the SATA controller: IDE device at targ 0, lun 0 lastlun 0x0 model ExcelStor Technology J880S ATA/ATAPI-7 supported, majver 0xfc minver 0x1a PCI-device: [EMAIL PROTECTED], ata0 ata0 is /[EMAIL PROTECTED],0/pci1166,[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL PROTECTED] UltraDMA mode 5 selected Disk0: Vendor 'Gen-ATA ' Product 'ExcelStor Techno' pci-ide, instance #0 Driver properties: name='class-code' type=int items=1 dev=none value=00010485 Hardware properties: name='#size-cells' type=int items=1 value= name='#address-cells' type=int items=1 value=0001 name='device_type' type=string items=1 value='pci-ide' [...] name='compatible' type=string items=7 value='pci1166,240.1166.24a.0' + pci1166,240.1166.24a' + 'pci1166,24a' + 'pci1166,240.0' + 'pci1166,240' + 'pciclass,010400' + 'pciclass,0104' name='model' type=string items=1 value='RAID controller' [...] ide, instance #0 System software properties: name='device_type' type=string items=1 value='ide' name='flow_control' type=string items=1 value='dmult' name='queue' type=string items=1 value='qfifo' name='max_transfer' type=int items=1 value=0100 name='ata-options' type=int items=1 value=0001 [...] ide (driver not attached) Hardware properties: name='reg' type=int items=1 value=0001 But attached are two disks (below are the boot messages of a Linux boot - but I want to get rid of Linux): Loading sata_svw ACPI: PCI Interrupt :01:0e.0[A] - GSI 11 (level, low) - IRQ 11 ata1: SATA max UDMA/133 cmd 0xC2004000 ctl 0xC2004020 bmdma 0xC2004030 irq 11 ata2: SATA max UDMA/133 cmd 0xC2004100 ctl 0xC2004120 bmdma 0xC2004130 irq 11 ata3: SATA max UDMA/133 cmd 0xC2004200 ctl 0xC2004220 bmdma 0xC2004230 irq 11 ata4: SATA max UDMA/133 cmd 0xC2004300 ctl 0xC2004320 bmdma 0xC2004330 irq 11 ata1: dev 0 ATA, max UDMA/133, 160836480 sectors: lba48 ata1: dev 0 configured for UDMA/133 scsi0 : sata_svw ata2: dev 0 ATA, max UDMA/133, 160836480 sectors: lba48 ata2: dev 0 configured for UDMA/133 scsi1 : sata_svw ata3: no device found (phy stat 0004) scsi2 : sata_svw ata4: no device found (phy stat 0004) scsi3 : sata_svw Vendor: ATA Model: ExcelStor Techno Rev: PF2O Type: Direct-Access ANSI SCSI revision: 05 SCSI device sda: 160836480 512-byte hdwr sectors (82348 MB) SCSI device sda: drive cache: write back SCSI device sda: 160836480 512-byte hdwr sectors (82348 MB) SCSI device sda: drive cache: write back sda: sda1 sda2 sda3 sda2: solaris: [s0] sda5 [s2] sda6 Attached scsi disk sda at scsi0, channel 0, id 0, lun 0 Vendor: ATA Model: ExcelStor Techno Rev: PF2O Type: Direct-Access ANSI SCSI revision: 05 SCSI device sdb: 160836480 512-byte hdwr sectors (82348 MB) SCSI device sdb: drive cache: write back Attached scsi generic sg0 at scsi0, channel 0, id 0, lun 0, type 0 SCSI device sdb: 160836480 512-byte hdwr sectors (82348 MB) SCSI device sdb: drive cache: write back sdb: sdb1 sdb2 sdb3 sdb2: solaris: [s0] sdb5 [s2] sdb6 Attached scsi disk sdb at scsi1, channel 0, id 0, lun 0 Attached scsi generic sg1 at scsi1, channel 0, id 0, lun 0, type 0 Any more ideas? Daniel ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] IDE driver attach to pseudo RAID-Controller
Hi, I try to install Solaris on a new machine. This machine contains an IDE controller with some Host-RAID controller - besides that you normally can still access the controller as a plain old IDE controller. But the BIOS has been set to enable RAID functionality (I am not able to change the BIOS settings). So the IDE controller identifies itself as PCI class 01-04-00 (Mass storage RAID controller) instead of PCI class 01-01-00 (Mass storage IDE controller) Excerpt from pciconf -v: pci1166,24a (driver not attached) Hardware properties: name='assigned-addresses' type=int items=30 value=81017010..bc00..0008.81017014..b880..0004.81017018..b800..0008.8101701c..b480..0004.81017020..b400..0020.82017024..fcafe000..2000 name='reg' type=int items=35 value=00017000.....01017010....0008.01017014....0004.01017018....0008.0101701c....0004.01017020....0020.02017024....2000 name='compatible' type=string items=7 value='pci1166,240.1166.24a.0' + 'pci1166,240.1166.24a' + 'pci1166,24a' + 'pci1166,240.0' + 'pci1166,240' + 'pciclass,010400' + 'pciclass,0104' name='model' type=string items=1 value='RAID controller' Is it possible for the Solaris ide driver to still attach to this device? This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Fujitsu's position to OpenSolaris?
Hi, can anyone comment what is Fujitsu's position to OpenSolaris? They also build SPARC machines but currently cannot run Solaris Nevada. I was curious because I saw populated directories in .../platform/sun4us .../platform/FJSV,GPUSK .../platform/FJSV,GPUZC-L etc. so I tried booting snv_37 on a PrimePower 1500 partition, but didn't have much luck: size: 0x734f8+0x2240a+0x442f2 Bytes module /platform/FJSV,GPUZC-L/kernel/sparcv9/unix: text at [0x100, 0x10734f7] data at 0x180 module misc/sparcv9/krtld: text at [0x10734f8, 0x108d16f] data at 0x1866700 module /platform/FJSV,GPUZC-L/kernel/sparcv9/genunix: text at [0x108d170, 0x11d21af] data at 0x186bf00 module /platform/FJSV,GPUZC-L/kernel/misc/sparcv9/platmod: text at [0x11d21b0, 0x11d3b17] data at 0x18bd1c0 module /platform/FJSV,GPUZC-L/kernel/cpu/sparcv9/FJSV,SPARC64-V: text at [0x11d3b20, 0x11dcfe7] data at 0x18bda40 SunOS Release 5.10 Version Generic 64-bit Copyright 1983-2005 Sun Microsystems, Inc. All rights reserved. Use is subject to license terms. /kernel/fs/sparcv9/specfs: undefined symbol 'lwp_stat_update' /kernel/fs/sparcv9/specfs: undefined symbol 'i_ddi_devi_attached' WARNING: mod_load: cannot load module 'specfs' (Can't load specfs) Program terminated Yes, this is really a boot of snv_37, but it seems the /platform/sun4us/kernel/sparcv9/unix file hadn't been updated since Solaris 10 GA. Daniel ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Fujitsu's position to OpenSolaris?
UNIX admin schrieb: SunOS Release 5.10 Version Generic 64-bit Copyright 1983-2005 Sun Microsystems, Inc. All rights reserved. Use is subject to license terms. Well, at least from the above we know that the kernel boots. The rest appears to be a problem with one of the kernel (fs) modules. Well, not really. What boots is a stock Solaris 10 kernel: SunOS Release 5.10 Version Generic 64-bit Copyright 1983-2005 Sun Microsystems, Inc. All rights reserved. Use is subject to license terms. These platform files for sun4us just fly around at Sun and don't get updated or recompiled. Later functions got added to the main kernel file, like: http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6216134 for this symbol below /kernel/fs/sparcv9/specfs: undefined symbol 'lwp_stat_update' or http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6369724 for /kernel/fs/sparcv9/specfs: undefined symbol 'i_ddi_devi_attached' But the sun4us-kernel never got updated, so this symbol cannot be resolved. I could try to use the files from the latest kernel patch (lwp_stat_update() was backported to Solaris 10 shortly after GA, but i_ddi_devi_attached() hasn't been backported yet), but this would just get me an ugly patched together system. I doubt such a mess would even get to single-user mode. Daniel ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] question concerning kstat's biostats, ufs_inode_cache, hsfs_hsnode_cache
Thomas Maier-Komor schrieb:
Hi,
I am once again looking at a kstat output and trying to understand what
some of these fields might mean and what their unit might be.
Unfortunately the units aren't documented anywhere, are they?
Use the source, Luke!
biostats is probably the statistics for the ddi I/O buffers of Solaris
that are accessible via bioinit(9f). So lookup and cache hits and misses
are counted here. Unit is probably each.
http://cvs.opensolaris.org/source/xref/on/usr/src/uts/common/os/bio.c#biostats
Later in the same file you can look up when the statistics will be
incremented. But I don't think biostats are of much interest any more.
Concerning ufs_inode_cache and hsfs_hsnode_cache, I'd like to know what
unit buf_inuse has. Is it kB or pages or something else?
Unit is number of elements, as with all kstat entries of class kmem_cache.
BTW: is the result sysconf(_SC_CPUID_MAX) the maximum id a processor can
have or the maximum id no processor will ever have?
Well, sysconf(_SC_CPUID_MAX) ends finally in the kernel:
http://cvs.opensolaris.org/source/xref/on/usr/src/uts/common/syscall/sysconfig.c#165
max_cpuid is initialized to a default value of (NCPU - 1) - some
architectures may re-set max_cpuid:
http://cvs.opensolaris.org/source/xref/on/usr/src/uts/common/os/cpu.c#max_cpuid
So _SC_CPUID_MAX returns the maximum possible value. If a architecture
supports cpuids from 0..31 (total 32 cpus) then sysconf(_SC_CPUID_MAX) will
return 31. So you should iterate over
for(cpuid = 0; cpuid = cpuid_max; ++cpuid)
...
But for my performance gathering tool I wrote a few years ago I didn't
bother to get _SC_CPUID_MAX at all. I just iterated over all kstat entries
while searching for the right kstat modules:
ncpu = 0;
for(ksp = kc-kc_chain; ksp != NULL; ksp = ksp-ks_next)
{
cpu_stat_t *cp;
if((ksp-ks_type != KSTAT_TYPE_RAW) ||
(strncmp(ksp-ks_module, cpu_stat, 8)))
continue;
if(kstat_read(kc, ksp, NULL) == -1)
continue;
++ncpu;
[...]
}
It really isn't that inefficient. Even on large machines with many RAM, lots
of disks and CPUs the cumulative running time was ~60 minutes over a period
of 200 days. The program fetched every 60 seconds performance counters from
disks, network, memory and cpu. Only on Solaris 2.6 accessing the kstat
system_misc module blocked for a few seconds on machines with large memory.
Daniel
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
Re: [osol-discuss] question concerning kstat's biostats, ufs_inode_cache, hsfs_hsnode_cache
Thomas Maier-Komor schrieb:
I also iterate only once and search for the modules/classes of interest.
Why do you use strncmp? Are ks_module and Co not guaranteed to be null
terminated or did you mix it up with ks_name which includes the trailing id?
Maybe just a leftover from an earlier implementation which iterated over
ksp-ks_name. strcmp() should be sufficient - the strings are null terminated.
Interesting experience - thanks for sharing it. I'd like to know if the
behavior concerning system_misc has improved with later Solaris releases...
Well, in Solaris 2.6 it took 2-3 seconds to read system_misc on a machine
with 32GB RAM and ~600 MHz CPUs. I skipped Solaris 7 and in 8 the problem
went away - so I don't know if it has been fixed in 7 or 8. The statistics
in system_misc were sometimes even unusable (pp_kernel had ridicilous high
values). Therefor I added some comments in the source code:
/*
* Zugriff auf system_pages braucht extrem viel Zeit (1s bei 32 GB RAM).
* Gibt es nicht etwas besseres?
*/
if((ksp = kstat_lookup(kc, unix, -1, system_pages)) == NULL)
return;
if(!kstat_read(kc, ksp, NULL))
return;
pp-kmem = data_lookup(kc, ksp, pp_kernel) * pagesize;
/* Bug in älteren Solaris-Versionen */
if(pp-kmem totalmem)
pp-kmem = 0;
Some other things you should consider (I fell into these traps while writing
my little program):
. altough the network drivers do have 64 bit counters in addition to
the 32 bit ones (obytes64, opackets64, rbytes64, ipackets64) - at
least for the bge driver these counters are still 32 bit values, so
they wrap at 2^32. So don't rely on these values really 64 bits wide.
. If you do DR operations or add/remove disks you have to kstat_close()
kstat_open() again - otherwise you won't notice the changed configuration.
. Also DR: Remember that on large machines if you detach a system board
some cpu_stat%d entries might vanish.
. If you count disk usage remember that SDS/SVM also registers its
devices to kstat. In my program I did calculate a disk I/O summary over
all disks and I wondered why on some machines these values were doubled
or 2.5x:
They were setup with SDS while other machines had VxVM (no kstat)
installed.
. Same goes for disk/partition kstat classes: don't count disk I/O twice.
Basically the relevant portion looks like:
for(ksp = kc-kc_chain; ksp != NULL; ksp = ksp-ks_next)
{
if(ksp-ks_type != KSTAT_TYPE_IO)
continue;
if(!strcmp(ksp-ks_module, md))
continue;
if(!strcmp(ksp-ks_class, partition))
continue;
kstat_read(kc, ksp, kio);
pp-rops += kio.reads;
pp-wops += kio.writes;
pp-rbytes += kio.nread;
pp-wbytes += kio.nwritten;
}
Daniel
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
Re: [osol-discuss] /usr/sbin/format: where is the -force flag?
Sarah Jelinek schrieb: Bill Sommerfeld wrote: It does allow you to change the sizes of partitions which are not in use, as long as they don't overlap in use partitions. It even lets you grow in use partitions. The heuristic of the vfstab being 'in use' could be improved upon however, which I believe is Daniel's main concern. The idea is that entries in /etc/vfstab are possibly in use, and designed to help users not step on filesystems that may not be mounted at that time, but could potentially be something they want to keep. In this special case it wasn't even a filesystem, but the swap device. You won't loose any vital data from an inactive swap device (ok, in theory you could loose a crash dump if you shrink swap). Daniel ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] getting current open FDs
alessioc schrieb: is there an equivalent to cat /proc/sys/fs/file-nr under Solaris to get the current number of open FDs? You mean the total number of open files in the system? kstat -n file_cache -s buf_inuse -- Daniel ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: getting current open FDs
alessioc schrieb: i mean the total number of open file descriptors, i'm not sure the command you reported shows this. (what i'm trying to transpose to solaris is the concept explained here: http://www.netadmintools.com/art295.html) Yes, the numbers should be the same. 1. On Solaris, there is no upper limit on the number of open descriptors 2. File descriptor memory is handled by the kmem_cache_* functions, see kmem_cache_create(9F), they maintain kstat info automatically. You can get the whole kmem_cache info for the file cache via kstat -n file_cache 3. More details on http://cvs.opensolaris.org/source/xref/on/usr/src/uts/common/os/fio.c Functions falloc() and unfalloc() -- Daniel ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Re: getting current open FDs
alessioc schrieb: There's no such limit in Solaris so there's no reason to make the number of file*s in use easily observable. not easily observable means that i can only do something like this? n=0; for i in $(find /proc -name fd -type d); do n=$[$(ls -l $i | wc -l) + $n]; done; echo $n This will get you wrong results: Inherited file descriptors will be counted multiple times. if you wonder why i should care about the amount of open FDs since there's no upper limit... well, i'm just curious to collect some statistics (without using dtrace :) My proposed kstat values should be the right ones. -- Daniel ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: RFE: /etc/systemtuneabletosetthedefaultpagesize
Dennis Clarke schrieb: In what sense? It already says the sun4u architecture doesn't support the 4K blocksize. It simply seems odd to refer to the 4K page size for the non-sun4u hardware when Solaris 10 does not support sun4m or sun4d etc etc. Simply leave the manpage with an 8K page size ( block size ) and leave it at that. Well, there still exists one non-sun4u supported hardware with even gaining popularity: i86pc. I still sometimes create filesystems with -b 4096 -f 512 (my news spool, performance doesn't matter, but size does). But why is UFS in Solaris limited to 8K blocks max? UFS on FreeBSD (even UFS1) uses 16K blocks as default for years. Daniel ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] AMD 64 X2 processor support
Felix Schulte schrieb: On 2/21/06, Ben Rockwood [EMAIL PROTECTED] wrote: Ken wrote: anyone have experience using solaris 10 with the amd 64 x2 processors? I am looking to build a rather cheap low end server. TIA Yes. ;) [EMAIL PROTECTED] ~$ psrinfo -vp The physical processor has 2 virtual processors (0 1) This is a bug. The chip has two physical processor cores and not two threads per core. Depends how you define physical and virtual. psrinfo(1M) defines physical==socket. psrinfo just reads the kstat module cpu_info and groups the ones with the same chip_id together: % kstat -m cpu_info module: cpu_infoinstance: 0 name: cpu_info0 class:misc brand AMD Athlon(tm) 64 X2 Dual Core Processor 4400+ chip_id 0 clock_MHz 2210 cpu_typei386 crtime 72.254744111 fpu_typei387 compatible implementation x86 (chipid 0x0 AuthenticAMD family 15 model 3 step 2 clock 2210 MHz) snaptime1900512.88014802 state on-line state_begin 1138644735 module: cpu_infoinstance: 1 name: cpu_info1 class:misc brand AMD Athlon(tm) 64 X2 Dual Core Processor 4400+ chip_id 0 clock_MHz 2210 cpu_typei386 crtime 75.192392263 fpu_typei387 compatible implementation x86 (chipid 0x0 AuthenticAMD family 15 model 3 step 2 clock 2210 MHz) snaptime1900512.88059098 state on-line state_begin 1138644740 % psrinfo -vp Der physische Prozessor verfügt über 2 virtuelle Prozessoren (0, 1) x86 (chipid 0x0 AuthenticAMD family 15 model 3 step 2 clock 2210 MHz) AMD Athlon(tm) 64 X2 Dual Core Processor 4400+ Daniel ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Strange CPU Utilization Problem
Jerry Gardner schrieb: My dual Opteron system running snv_27 occasionally gets into a state where processor utilization goes to 100% on one processor for a second or two and then drops back to zero, and then the whole cycle repeats on the other processor. The system is not doing anything processor-intensive when this happens--it's just sitting at the JDS screen. This continues until the system is rebooted. Sounds at least partly familiar for me. Does the system become sluggish after a few hours? I too saw strange CPU utilisation jumps, strange statistics counters, etc. Anyone else see this? Is there a fix? My problem was related to the bug below http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6336786 Haven't heard that Dual Opterons were also affected. But the bug is a BIOS issue, no processor issue. Since Opterons are targeted for another market than Athlon64, they usually don't program activate those fancy power saving features into the BIOS. Maybe not in your case. Daniel ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] milestone none really means nothing running at all really
Joerg Schilling schrieb: [EMAIL PROTECTED] wrote: When you boot from a device the node does not need to be present in /dev* in order for you to remoutn it r/w so you can fix it. This was true before /devices was on the devfs filesystem. But having /usr ready helps a lot. It is no fun, cd'ing into /devices, doing an echo * just to find out where your /usr might be located. You may have to write a cat replacement in sh, cannot grep into files, etc. So with devfs it should be possible to recover with a separate /usr; OTOH having a unified / /usr eases recovery a lot. Daniel ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] fsck seems to have a few new features in build 26
Jonathan Adams schrieb: On Tue, Nov 15, 2005 at 08:06:06PM -0500, Dennis Clarke wrote: Hold on .. do you mean from the ok prompt ? ok boot -m milestone=none as opposed to ok boot -sv hmmm fascinating ... let me try that right now. Yes; it's a completely minimal boot, with nothing but init(1M), svc.startd(1M), svc.configd(1M), and sulogin(1M) running. Finally we have an official replacement for the undocumented boot -b flag in earlier Solaris releases. Daniel ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] inode numbers on ZFS
[EMAIL PROTECTED] schrieb: ZFS is a 128 bit filesystem, isn't it? Depends on whether it's large file aware or not, I'd say. (the ino field in stat64 is 64 bits) So to fully utilize a ZFS file system the average file size has to be 16 EB? People are already moaning today that on MT-UFS the average file size has to be 1 MB... I hope it is just an interface limitation and that ZFS's internals don't impose such a limit. Daniel ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: zfs
Joerg Schilling schrieb: At mount time the correctness of Bill Joy's birthday needs to be verified Actually, it is Kirk's birthday. Daniel ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: zfs
Joerg Schilling schrieb: Daniel Rock [EMAIL PROTECTED] wrote: With a UFS version from SunOS-4.0 (1987) or later, newfs of course and even by default uses bigger values (depending on the geometry and size of the disk). BTW: The number of inodes/cylinder group is unrelated to the number of cylinders per group. If you want to enlarge cpg, with the same amount of total inodes in the file system, you'll need more space for the inode bitmap in the cg superblock. But the cg superblock is limited to one fs block. So to use a larger cpg value you usually have to decrease the inode density. This is what I said: The clean flag was always in (but unused). SunOS-4.1 did introduce it around 1989. FreeBSD did introduce an incomatible implementation after 1993.. Who cares. I already told you, that I had to fsck the filesystem anyway before using it on the other system, so the fs_clean flag was irrelevant. WRONG: Nothing did shift caused ny the shadow inode. I said that they are on shifted locations. I didn't say that they were once shifted on purpuse in the same implementation. I have done it back these days several times. I used an UFS formatted ZIP disk for data exchange between FreeBSD and Solaris/x86. It was far from perfect, but it worked at least for regular files and directories. I didn't have any intention for using more features. If you did do the exchange between FreeBSD and an old Solaris version that still did use ic_oeftflag, you may have had more luck then now. Like I said: Back these days. I also pointed out several times, that it may not work with newer releases anymore. But what is your point? We all know that *BSD's and Solaris' UFS have subtle differences. I just said, that I once was able to ignore these differences and was able to read and write UFS file systems on the other system. Daniel ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
