New Solaris 7 features
Alan Cox
Except on the half of the ultrasparcs, where 64bit stuff is
mostly disabled because of CPU bugs ;) (See Bugtraq)
> - UFS logging (mount -o logging /dev/dsk/c0t0d0s0 /mnt)
Thats been in for years, I think you just used to pay for it. Its nice
very nice.
> - mount "noatime" support
They're catching up with us
> - TCP performance enhancement with SACK, RFC 2018
In 2.1.x this is good that Solaris has it too - it really helps with hosts
that also talk SACK on bad links. It now looks like most non MS OS's will
be shipping SACK support very soon, and probably MS too.
> - Netscape 4.05
4.05 is insecure, and 4.5 is out ;)
> - directory name lookup cache optimized and now dynamically allocated on
> demand (static before)
We've got one of those too.
> traceroute
Whooo they've finally _10 years after asking_ got traceroute ;)
> - File Access Control Lists "facls" (man setfacl) added with Solaris 2.5.1
> are damn usefull.
Theres a project with those in ext2fs too .
Interesting list. Did they post lmbench figures ;)
Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
c...@ix.net.nz
> - Can address 17.5 terabytes of memory, 9TB files
In theory, so can linux (on the alpha and ultra)
> - Arithmetic computations get to use 64-bit registers and operations
So can linux
> - UFS logging (mount -o logging /dev/dsk/c0t0d0s0 /mnt)
linux 2.3.x will probably have this
> - mount "noatime" support
something linux has had for eons
> - TCP performance enhancement with SACK, RFC 2018
something linux has had for a few months now
> - New crash dump features
something we don't have - and might be useful (I know we've had this
discussion a long time back when Linus said he didn't find them
useful or something)
> - BIND 8.1.2
so does linux (most recent. distrubutions anyhow)
> - Sendmail 8.9.1b
go it too
> - improved poll(2) system call (used in many applications)
not sure what imporved means, but poll(2) we got and have had for a
while now
> - increase in number of filedescriptors
actually, this is a killer for 2.1.x / 2.2.x - Bill Hawes did some
stuff to make this number dynamic, but I could never get it working
properly with gobs of FDs. We need gobs of FDs, really we do.
> - Full Unicode 2.1 support
dont have it
> - Better threading subsystem
we don't have lwp of threads, 2.3.x maybe
> - Lots of new CDE apps/improvements
gnome
> - Netscape 4.05
got it
> - directory name lookup cache optimized and now dynamically allocated on
> demand (static before)
umm... got this I think
> - significantly improved paging algorithim, not "on" by default
> add the line: set priority_paging = 1 to /etc/system, and reboot
> - Note, backported to 2.6 kernel patch "-09"
> http://www.sun.com/sun-on-net/performance/priority_paging.html
> IMPORTANT NOTE: Ensure that data files do not have the executable
> bit set. This can fool the VM into thinking that these are really
> executables, and will not engage priority paging on these files.
no idea how we stack up here... last time I did any comparisons Sunos
4.1.3U2 seemed to page _much_ better than linux on the same box, but
I think this was a hacked 2.0.x or early 2.1.x kernel...
> - some new commands like
> plimit(1): Set or get resource limits of a process by taking a
> process ID (PID) as an argument (limit and ulimit only work with the
> current process)
don't have this... but it wouldn't be hard to add
> pgrep(1): Find a process by name and print the PID
pidof (had for a long time)
> pkill(1): Find a process by name and send it a signal specified on
> the command line
kill `pidof process`
?
a 2 line script maybe...
> traceroute
had it for eons
> - File Access Control Lists "facls" (man setfacl) added with Solaris 2.5.1
> are damn usefull.
another linux 2.3.x thing (maybe?)
I guess I'm just not easily impressed...
-cw
Larry McVoy
:
: Whooo they've finally _10 years after asking_ got traceroute ;)
Yeah, they had to shit traceroute now that we have mtr, a nicer replacement.
: Interesting list. Did they post lmbench figures ;)
No, but I probabl have 'em somewhere. Unless they have screwed something up,
the curves were all in the right direction, i.e., they are getting better -
but Linux still smokes 'em on the microbenchmarks.
Harald Dunkel
>
> > - Arithmetic computations get to use 64-bit registers and operations
>
> mostly disabled because of CPU bugs ;) (See Bugtraq)
>
Maybe it's beyond the scope of this mailing list, but:
How can I check whether an Ultra workstation running SunOS 5.7
uses 64bit features instead of workarounds based on the old
32bit functionality? I would like to get an algorithm to
identify these broken CPUs.
Regards
Harri
--
Harald Dunkel | dun...@Synopsys.COM | O glücklich, wer noch hoffen kann,
Synopsys GmbH | Kaiserstr. 100 | aus diesem Meer des Irrtums
52134 Herzogenrath, Germany | aufzutauchen. Faust,
+49 2407 9558 (fax? 44: 0) | Der Tragödie erster Teil, J.W.G.
Jakub Jelinek
> Alan Cox wrote:
> >
> > > - Arithmetic computations get to use 64-bit registers and operations
> >
> > Except on the half of the ultrasparcs, where 64bit stuff is
> > mostly disabled because of CPU bugs ;) (See Bugtraq)
> >
>
> Maybe it's beyond the scope of this mailing list, but:
>
> How can I check whether an Ultra workstation running SunOS 5.7
> uses 64bit features instead of workarounds based on the old
> 32bit functionality? I would like to get an algorithm to
> identify these broken CPUs.
Its easy. If you have UltraSPARC I, you loose with Solaris (Linux will have
a workaround), if you have II or IIi, you can run 64bit apps just fine.
Cheers,
Jakub
___________________________________________________________________
Jakub Jelinek | j...@sunsite.mff.cuni.cz | http://sunsite.mff.cuni.cz
Administrator of SunSITE Czech Republic, MFF, Charles University
___________________________________________________________________
Ultralinux - first 64bit OS to take full power of the UltraSparc
Linux version 2.1.127 on a sparc64 machine (498.80 BogoMips).
___________________________________________________________________
Malcolm Beattie
> > - UFS logging (mount -o logging /dev/dsk/c0t0d0s0 /mnt)
>
> very nice.
I don't think the "same disk" option has been in before. You used to
have to use Solstice disksuite and prepare a separate log partition in
advance (which is a pain in itself when trying to carve up a large
disk array and you only have a stupid 7 slot disklabel to play with).
With Solaris 2.^H^H7, it's just a mount time option to add a log on
the fly on the same partition. You lose performance though over having
a separate spindle for logging.
While I'm here: an idea for providing a snapshot capability to any
block device (allowing you to snapshot then backup any fs you like).
A fake block device /dev/snap which you connect to the
device-to-be-snapshotted on one side and to a spare block device on
the other side (either a spare partition or a /dev/loop on a file).
snap keeps a dirty bitmap and a sparse block structure on the spare
block device. Writes to snap mark the block in the dirty bitmap and
store the original block in the sparse structure. Reads from snap
check the dirty bitmap and read from the original or the sparse block
map.
Usage would be a bit like the loop block device. When you want to
snapshot device /dev/sda1 on spare partition /dev/sdb2 you do
snapsetup /dev/snap0 /dev/sda1 /dev/sdb2
and that starts dribbling the originals of any blocks changed on
/dev/sda1 to /dev/sdb2 (stored sparsely). Then you backup /dev/snap0.
When you've finished, you stop the snap0 device. Has anyone else got
something around that does that or should I try to persuade/help
someone to do it?
--Malcolm
--
Malcolm Beattie <mbea...@sable.ox.ac.uk>
Unix Systems Programmer
Oxford University Computing Services
Mailing List Account
> : Whooo they've finally _10 years after asking_ got traceroute ;)
>
> Yeah, they had to shit traceroute now that we have mtr, a nicer
> replacement.
I would think with tens of paid developers and a reasonable budget,
sun could be catching up more quickly... but it doesn't seem that
way.
> : Interesting list. Did they post lmbench figures ;)
>
> No, but I probabl have 'em somewhere. Unless they have screwed
> something up, the curves were all in the right direction, i.e.,
> they are getting better - but Linux still smokes 'em on the
> microbenchmarks.
Ironically, as most OSs seem to get faster as they evolve and are
tuned on the same hardware, Windahs variants are getting
progressively slower - it only increases in processing power that
make it feasible to run them.
Linux on the machine I have access to, generally has gotten quicker
and better as its evolved, Sure, it slower on small memory machines
because it also got larger, but with enough memory, 2.1.x seems
pretty quick compared to 2.0.x for many things.
OTOH, Windows98 on a Pentium ][ 266 is about as usable as Windows95
on a 486/100.
(just how things fell, not actually tested)
Me thinks maybe M$ biggest threat is M$.
-cw
Nick Holloway
> > - Arithmetic computations get to use 64-bit registers and operations
>
> Except on the half of the ultrasparcs, where 64bit stuff is
> mostly disabled because of CPU bugs ;) (See Bugtraq)
What does Linux/sparc64 do with these chips?
--
`O O' | Home: Nick.H...@alfie.demon.co.uk http://www.alfie.demon.co.uk/
// ^ \\ | Work: Nick.H...@parallax.co.uk