On Sun, Aug 5, 2012 at 9:25 PM, SilverTip257 <silvertip257@gmail.com> wrote:
> Recent and Future Adventures in Filesystem Scalability - Dave Chinner
Thanks for that vid!
FC
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
08-06-2012, 10:00 AM
compare zfs xfs and jfs o
Karanbir Singh <mail-lists@karan.org> wrote:
> On 08/04/2012 08:32 PM, Joerg Schilling wrote:
> > I would not call it a rant but a food for thought.
>
> agreed!
>
> > ZFS was distributed to the public after it turned 4.
> > ZFS is now in public use since more than 7 years.
>
> but ZFS has not had a stable release in Linux as yet, making it still be
> negative in years. The codebase is likely to take a lot longer to get
> into a stable status than btrfs.
The ZFS code base is stable, the problem is the VFS interface in Linux and that
applies to all filesystems....
> > So be careful with BTRFS until it was in wide use for at least 4 years.
>
> So, I'm all for mature and tested systems - always. But given the
> problem domain, I think its wrong to generalise to that level. Lots of
> people will use technology on the cutting edge, and lots more people
> will adopt for feature matching with app domains. I, for one, am
> grateful to these people for picking up the stuff in its early days and
> working to find and then even fix issues as they come up.
The ZFS developers have been forced by Sun to put their home directoriers on
ZFS in 2001. Does this apply to BTRFS too?
> > ZFS is the best I know for filesystems >= 2 TB and in case you need flexible
> > snapshots. ZFS has just one single problem, it is slow in case you ask it to
> > verify a stable FS state, UFS is much faster here, but this ZFS "problem" is
> > true for all filesystems on Linux because of the implementation of the Linux
> > buffer cache.
>
> the other problem with zfs is its large RAM requirements - and extremely
> poor 32bit support.
This is not a problem as nobody encourages you to put ZFS into toys or phones.
With the typical amout of RAM in today's machines, ZFS is happy.
> > Again:
> >
> > - NFSv2 (from 1988) allows 32 Bytes for a NFS file handle
> >
> > - NFSv3 (from 1990) allows 64 Bytes for a NFS file handle
> >
> > - NFSv4 (from 2004) has no hard limit here
> >
> > With the 32 byte file handle, there are still 12 bytes (including a 2 byte
> > length indicator) for the file id in the file handle.
> >
> > If your filesystem could use 44 and more bytes in the case you describe, there
> > is no problem - except when the code is not OK.
> >
> > It is of course nice to still support SunOS-4.0 clients, but in case that the
> > client supports NFSv3 or newer, why not use longer file id's?
> >
>
> we had both solaris 10 aka sunos 5.10 clients and EL5/6 clients. the
> error is "Stale NFS file handle"
So the bug is in the NFS server code.
A NFS file handle is made of a filesystem ID, a file ID for the export
directory and a file ID for the current file.
A file ID is (for a writable filesystem) typically made of the inode number and
a file generation number that is incremented every time a destructive operation
on the file appears.
"Stale NFS file handle" is the error code if the referred file (inode number +
file generation number) no longer exists.
I asume that in your case, the server did send out invalid file IDs that do not
point to a valid file. For this reason, the client gets a "Stale NFS file
handle" when it uses the NFS file handle returned by the NFS server for a
open() operation.
> anyways, this refers to the fsid problem,
> http://xfs.org/index.php/XFS_FAQ#Q:_Why_doesn.27t_NFS-exporting_subdirectories_of_inode64-mounted_filesystem_work.3F
This seems to be an "explanation" from the people who wrote the non-working NFS
code.
> we were unable to make the 'fsid=uuid' option work (or we didn't
> understand it), but using fsid=## for unique integers for each export
> works fine, so thats what we went with.
>
> are these fsid's the same as your 32 vs 64 bit file handles ? doesn't
> sound like it to me, unless I'm misunderstanding what you're referring
> to as a file handle.
If you introduce new words, you would need to explain them. I can only explain
how NFS works and that it is possible to use NFS to export filesystems with
more than 32 bit inode numbers.
Just a note: even with NFSv2, you could have an 8 Byte inode number + 2 Byte
file generation number or 7 Byte inode number + 3 byte file generation number
or 6 Byte inode number + 4 Byte file generation number.
It is most unlikely that a filesystem designed for NFSv2 export will use the
full 8 byte address space that 64 bit inode number could allow.
Mon Aug 6 12:30:01 2012
Return-Path: <gentoo-dev+bounces-53799-tom=linux-archive.org@lists.gentoo.org>
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on
eagle542.startdedicated.com
X-Spam-Level:
X-Spam-Status: No, score=-5.0 required=5.0 tests=RCVD_IN_DNSWL_HI,
SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2
X-Original-To: tom@linux-archive.org
Delivered-To: tom-linux-archive.org@eagle542.startdedicated.com
Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80])
by eagle542.startdedicated.com (Postfix) with ESMTP id 8347720E0054
for <tom@linux-archive.org>; Mon, 6 Aug 2012 12:27:10 +0200 (CEST)
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
by pigeon.gentoo.org (Postfix) with SMTP id CCA7BE076F;
Mon, 6 Aug 2012 10:26:46 +0000 (UTC)
X-Original-To: gentoo-dev@lists.gentoo.org
Delivered-To: gentoo-dev@lists.gentoo.org
Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183])
by pigeon.gentoo.org (Postfix) with ESMTP id A34AFE06C0
for <gentoo-dev@lists.gentoo.org>; Mon, 6 Aug 2012 10:24:00 +0000 (UTC)
Received: from [192.168.178.29] (e178072006.adsl.alicedsl.de [85.178.72.6])
(using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits))
(No client certificate requested)
(Authenticated sender: chithanh)
by smtp.gentoo.org (Postfix) with ESMTPSA id 87BE81B4003
for <gentoo-dev@lists.gentoo.org>; Mon, 6 Aug 2012 10:23:59 +0000 (UTC)
Message-ID: <501F9B4C.6020401@gentoo.org>
Date: Mon, 06 Aug 2012 12:24:12 +0200
From: =?UTF-8?B?Q2jDrS1UaGFuaCBDaHJpc3RvcGhlciBOZ3V54buFbg==? <chithanh@gentoo.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120729 Firefox/14.0.1 SeaMonkey/2.11
Precedence: bulk
List-Post: <mailto:gentoo-dev@lists.gentoo.org>
List-Help: <mailto:gentoo-dev+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-dev+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-dev+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org>
X-BeenThere: gentoo-dev@lists.gentoo.org
Reply-to: gentoo-dev@lists.gentoo.org
MIME-Version: 1.0
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] force verbose build log as per PMS policy?
References: <50190F67.9060900@gentoo.org>
In-Reply-To: <50190F67.9060900@gentoo.org>
X-Enigmail-Version: 1.5a1pre
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
hasufell schrieb:
> When I sum that up again...
> - we are on gentoo and need as much information as possible for
> backtracing, resolving bugs, checking whether CFLAGS and such have been
> respected
> - no need to tell the user to recompile with
> EXTRA_ECONF="--disable-silent-rules" or similar just to be able to help him
> - some QA checks might depend on verbose build log and are not yet
> implemented therefor
> - if people want nice build _output_ (not log), they can use --quiet-build
Sorry that I am late to the party, but I would add some concerns to this
discussion.
Verbose build logs are can be several times as large as non-verbose
ones, which can run into our Bugzilla's attachment size limit. When a
user is unable to attach the build.log file, typically one of the
following happens:
1. User compresses build.log with a common compressor like gzip, bzip2
or xz and manually sets the attachment MIME type correctly (best case).
2. User makes a compressed tarball, containing a single file
3. User cuts off the build.log somewhere in the middle, supplies the
bottom part
4. User uploads build.log to a public file hoster or his own private web
server, the link expires / 404s after some time (IMO worst case).
In my opinion, build verbosity should not be dictated by policy, but
rather left to the discretion of the maintainer. After all, he is the
one who needs to deal with the bug reports.
Having verbose build logs by default (with the possibility for the
maintainer to override) would be ok with me though.
Best regards,
ChÃ*-Thanh Christopher Nguyá»?n
08-06-2012, 10:44 PM
Warren Young
compare zfs xfs and jfs o
On 8/4/2012 9:21 AM, Johnny Hughes wrote:
>
> ext4 is the OS that RHEL and Fedora support as
> their main file system. I would (and do) use that. The 6.3 kernel does
> support xfs and CentOS has the jfs tools in our extras directory, but I
> like tried and true over experimental.
xfs still has at least one big advantage over ext4 on EL6, AFAIK:
supporting filesystems over 16 TB.
I am aware that ext4 is supposed to support 1 EiB filesystems[1], but
due to a bug in e2fsprogs 1.41 (what EL6 ships) there is an artificial
16 TB limit[2].
I know we all like to pride ourselves on "stable" package versions, but
this bug was fixed in the very next feature release of e2fsprogs, 1.42.
Johnny, do you have any insight into why upstream isn't making an
exception here, as they have for, say, Firefox? Surely they aren't
going to hold it for EL7 and tout it as a "feature"?
Perhaps I am being unfair. Did they backport the bug fix only, and my
failure to mkfs.ext4 a 22 TB partition was due to some other problem?
If someone wants me to try something, it'll have to wait at least a few
weeks. That's the earliest I'm likely to have a > 16 TB RAID sitting
around ready to be nuke-and-paved at a whim.
[1] https://en.wikipedia.org/wiki/Ext4
[2] http://e2fsprogs.sourceforge.net/e2fsprogs-release.html#1.42
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
08-07-2012, 09:57 PM
Pasi Kärkkäinen
compare zfs xfs and jfs o
On Mon, Aug 06, 2012 at 12:00:22PM +0200, Joerg Schilling wrote:
> Karanbir Singh <mail-lists@karan.org> wrote:
>
> > On 08/04/2012 08:32 PM, Joerg Schilling wrote:
> > > I would not call it a rant but a food for thought.
> >
> > agreed!
> >
> > > ZFS was distributed to the public after it turned 4.
> > > ZFS is now in public use since more than 7 years.
> >
> > but ZFS has not had a stable release in Linux as yet, making it still be
> > negative in years. The codebase is likely to take a lot longer to get
> > into a stable status than btrfs.
>
> The ZFS code base is stable, the problem is the VFS interface in Linux and that
> applies to all filesystems....
>
Hello,
Care to explain what's the problem in Linux VFS layer ?
-- Pasi
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
08-08-2012, 10:11 AM
compare zfs xfs and jfs o
Pasi Kärkkäinen <pasik@iki.fi> wrote:
> > The ZFS code base is stable, the problem is the VFS interface in Linux and that
> > applies to all filesystems....
> >
>
> Hello,
>
> Care to explain what's the problem in Linux VFS layer ?
The VFS layer was introduced in 1980 by Bill Joy when he started the UFS
project (his master thesis).
The VFS layer was enhanced around 1984/1985 to support NFS.
The VFS layer was enhanced again in 1987 to support mmap() and the new momory
model from SunOS-4.0 that has been copied by all major OS.
In 1993, VFS was enhanced to support ACLs.
In 2007, VFS was enhanced to support CIFS (e.g. atomic create with ACL, switch
into case insensitive mode, ...).
VFS has a 30 year history and offers a clean abstract design. It is even
independent from typical changes in the proc or user structures. It uses vnodes
instead of inodes to grant a clean abstraction level.
Linux VFS looks not very abstract, it is directly bound to user/proc structures
and to Linux I/O. There is no support for NFS (get fid from vnode and get vnode
from fid). There is no support for ACLs (let the filesystem decide whether
access should be granted).
The deviating I/O model in Linux will cause a lot of work for adaptation....
What about extended attribute files (the superset of Win-DOS streams)?
On Sat, 2012-08-04 at 10:21 -0500, Johnny Hughes wrote:
> On 08/04/2012 09:36 AM, ashkab rahmani wrote:
> > thank you. very usefull
> > i think i'll try btrfs or jfs,
> > i'll send you btrfs result for you.
> >
> > On Sat, Aug 4, 2012 at 6:58 PM, Nux! <nux@li.nux.ro> wrote:
> >
> >> On 04.08.2012 15:19, ashkab rahmani wrote:
> >>> thank you i have redundancy but i have simplified scenario.
> >>> but i think ext4 is notbas fast as others. is it true?
> >>>
> >>>> On 04.08.2012 15:01, ashkab rahmani wrote:
> >>>>> hello
> >>>>> i have 16tb storage. 8x2tb sata raided.
> >>>>> i want to share it on network via nfs.
> >>>>> which file system is better for it?
> >>>>> thank you
> >>>> No redundancy? That's a lot of data to lose. :-)
> >>>>
> >>>> As for your question, I'd use ext4. It has caught up a lot with XFS
> >>>> and
> >>>> it's THE file system supported by RHEL and Fedora.
> >>>>
> >>>> Well, I think ext4 is pretty fast. Maybe XFS has a slight edge over it
> >>>> in some scenarios.
> >>>> ZFS on linux is still highly experimental and has received close to no
> >>>> testing.
> >>>> If you are in mood for experiments EL6.3 includes BTRFS as technology
> >>>> preview for 64bit machines. Give it a try and let us know how it goes.
> >>>>
>
> Personally, I would use ext4 ... faster is not always better.
+1 ext4 is 'plenty good', bullet proof, and robustly supported.
What ext4 suffers most from is hangover impressions of its quality that
have followed it from early ext3 [even later versions of ext3 were
considerably better than early ext3; especially with the introduction
of dir_index that solved a lot of big-folders-are-very-slow problems].
ext4 uses extents, just like XFS. It can pre-allocate just like XFS.
It does delated allocation, like XFS.
If you want really good performance than putting your journal external
to the filesystem, preferably on really fast storage, will probably help
more than anything else. Certainly more than type-of-filesystem.
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
08-12-2012, 01:17 AM
Gordon Messmer
compare zfs xfs and jfs o
On 08/04/2012 07:01 AM, ashkab rahmani wrote:
> i want to share it on network via nfs.
> which file system is better for it?
I have a hard time imagining that you'd get useful information from
cross-posting this to the FreeBSD and CentOS lists. Their
implementations of filesystems are completely different.
If you use a CentOS NFS server, I'd recommend ext4. In benchmarks, I
often see XFS perform better than ext4 in specific tests. JFS rarely
does well. However, the last time I used XFS was for a system running
Zoneminder. Benchmarks let us to believe that XFS would be a better
filesystem, but in our actual implementation it couldn't keep up. The
application couldn't delete data quickly enough when the volume was
nearly full, so the volume would fill up and the system would fail. We
only got it working reliably after switching to ext4.
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
08-12-2012, 10:31 AM
compare zfs xfs and jfs o
Gordon Messmer <yinyang@eburg.com> wrote:
> On 08/04/2012 07:01 AM, ashkab rahmani wrote:
> > i want to share it on network via nfs.
> > which file system is better for it?
>
> I have a hard time imagining that you'd get useful information from
> cross-posting this to the FreeBSD and CentOS lists. Their
> implementations of filesystems are completely different.
>
> If you use a CentOS NFS server, I'd recommend ext4. In benchmarks, I
Whatever you do, don't use bemchmarks to compare Linux with other OS, Linux
cheats.
A benchmark tries to do something completed and then get the time for that but
I've seen Linux to try it's best to prevent this completed set of actions to
happen withing a known time.
If I unpack the linux kernel sources on Solaris and UFS using star (that by
default calls fsync() for each file) everything is stable on disk when star
finishes.
If you do the same on Linux/ext3 with gnu tar, gtar finishes 10-30% faster than
star does on Solaris but on Linux almost nothing is on disk at that time.
If you like to compare, I recommend to use gtar or star -no-fsync to unpack the
linux kernel sources and to pull the mains plug after the tar extract seems to
be ready (the next prompt is displayed). Then reboot and compare what you have
on disk an whether the filesystem on disk is still usable.
>
> Whatever you do, don't use bemchmarks to compare Linux with other OS,
> Linux cheats.
>
> A benchmark tries to do something completed and then get the time for
> that but
> I've seen Linux to try it's best to prevent this completed set of
> actions to
> happen withing a known time.
>
> If I unpack the linux kernel sources on Solaris and UFS using star
> (that by
> default calls fsync() for each file) everything is stable on disk when
> star
> finishes.
>
A little data never hurts. Even if the numbers mean little.
test 1 - Debian Linux 6.0.5 on x86_64
root@tfs01:/usr/local# uname -a
Linux tfs01 2.6.32-5-amd64 #1 SMP Sun May 6 04:00:17 UTC 2012 x86_64 GNU/Linux
root@tfs01:/usr/local# cat /etc/debian_version
6.0.5
root@tfs01:/usr/local# cd src
root@tfs01:/usr/local/src# ls -a
. ..
root@tfs01:/usr/local/src#
root@tfs01:/usr/local/src# wget http://www.kernel.org/pub/linux/kernel/v3.0/linux-3.5.1.tar.bz2
--2012-08-12 20:39:18-- http://www.kernel.org/pub/linux/kernel/v3.0/linux-3.5.1.tar.bz2
Resolving www.kernel.org... 149.20.4.69, 149.20.20.133
Connecting to www.kernel.org|149.20.4.69|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 80981090 (77M) [application/x-bzip2]
Saving to: `linux-3.5.1.tar.bz2'
100%[======================================>] 80,981,090 871K/s in 92s
root@tfs01:/usr/local/src# time -p openssl dgst -sha256 linux-3.5.1.tar.bz2
SHA256(linux-3.5.1.tar.bz2)= 78f8553c7cbc09d9c12d45c7f6ec82f964bf35d324832bede2 73ba2f6fe3e3ed
real 0.85
user 0.78
sys 0.02
CPU type :
root@tfs01:/usr/local/src# grep -E "^processor|^vendor_id|^model name" /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
model name : AMD Opteron(TM) Processor 6272
processor : 1
vendor_id : AuthenticAMD
model name : AMD Opteron(TM) Processor 6272
processor : 2
vendor_id : AuthenticAMD
model name : AMD Opteron(TM) Processor 6272
processor : 3
vendor_id : AuthenticAMD
model name : AMD Opteron(TM) Processor 6272
root@tfs01:/usr/local/src# mkdir foo
root@tfs01:/usr/local/src# cd foo
root@tfs01:/usr/local/src/foo# /opt/schily/bin/star -x -bz -xdir -xdot -U -fs=64m -fifostats -time file=../linux-3.5.1.tar.bz2 ; find . -type f | wc -l
star: fifo had 46849 puts 80626 gets.
star: fifo was 1 times empty and 12 times full.
star: fifo held 67112960 bytes max, size was 67112960 bytes
star: fifo had 5 moves, total of 25600 moved bytes
star: fifo is 0% full (2k), size 65540k.
star: 46849 blocks + 0 bytes (total of 479733760 bytes = 468490.00k).
star: Total time 73.528sec (6371 kBytes/sec)
39096
root@tfs01:/usr/local/src/foo# cd ..
root@tfs01:/usr/local/src# time -p rm -rf foo
real 0.97
user 0.01
sys 0.94
root@tfs01:/usr/local/src# mkdir doo
root@tfs01:/usr/local/src# cd doo
root@tfs01:/usr/local/src/doo# which tar
/bin/tar
root@tfs01:/usr/local/src/doo# time -p tar --use-compress-program /bin/bzip2 -xf ../linux-3.5.1.tar.bz2 ; find . -type f | wc -l
real 25.14
user 24.03
sys 4.48
39096
Let's try that without compression involved.
root@tfs01:/usr/local/src# bunzip2 linux-3.5.1.tar.bz2
root@tfs01:/usr/local/src#
root@tfs01:/usr/local/src# ls -lApb
total 468956
-rw-r--r-- 1 root staff 479733760 Aug 9 15:44 linux-3.5.1.tar
root@tfs01:/usr/local/src# mkdir foo
root@tfs01:/usr/local/src# cd foo
root@tfs01:/usr/local/src/foo# time -p /opt/schily/bin/star -x -xdir -xdot -U -fs=64m -fifostats -time file=../linux-3.5.1.tar
star: fifo had 46849 puts 80626 gets.
star: fifo was 1 times empty and 19 times full.
star: fifo held 67112960 bytes max, size was 67112960 bytes
star: fifo had 5 moves, total of 25600 moved bytes
star: fifo is 0% full (2k), size 65540k.
star: 46849 blocks + 0 bytes (total of 479733760 bytes = 468490.00k).
star: Total time 73.252sec (6395 kBytes/sec)
real 73.33
user 0.53
sys 5.77
root@tfs01:/usr/local/src/foo# cd ..
root@tfs01:/usr/local/src# rm -rf foo
root@tfs01:/usr/local/src# mkdir doo
root@tfs01:/usr/local/src# cd doo
root@tfs01:/usr/local/src/doo# time -p tar -xf ../linux-3.5.1.tar
real 3.13
user 0.22
sys 2.80
3 seconds ? I find that a tad hard to believe.
test 2 - Solaris 10 on HP Server x86_64 with ZFS
$ uname -a
SunOS foxtrot 5.10 Generic_147441-19 i86pc i386 i86pc
$ cat /etc/release
Oracle Solaris 10 8/11 s10x_u10wos_17b X86
Copyright (c) 1983, 2011, Oracle and/or its affiliates. All rights reserved.
Assembled 23 August 2011
$ zpool list
NAME SIZE ALLOC FREE CAP HEALTH ALTROOT
foxtrot_rpool 1.62T 66.1G 1.56T 3% ONLINE -
$ zpool get all foxtrot_rpool
NAME PROPERTY VALUE SOURCE
foxtrot_rpool size 1.62T -
foxtrot_rpool capacity 3% -
foxtrot_rpool altroot - default
foxtrot_rpool health ONLINE -
foxtrot_rpool guid 14156136675261437976 default
foxtrot_rpool version 29 default
foxtrot_rpool bootfs foxtrot_rpool/ROOT/s10x_u10wos_17b local
foxtrot_rpool delegation on default
foxtrot_rpool autoreplace off default
foxtrot_rpool cachefile - default
foxtrot_rpool failmode continue local
foxtrot_rpool listsnapshots on default
foxtrot_rpool autoexpand off default
foxtrot_rpool free 1.56T -
foxtrot_rpool allocated 66.1G -
foxtrot_rpool readonly off -
$ psrinfo -pv
The physical processor has 12 virtual processors (0 2 4 6 8 10 12 14 16 18 20 22)
x86 (chipid 0x0 GenuineIntel family 6 model 44 step 2 clock 3467 MHz)
Intel(r) Xeon(r) CPU X5690 @ 3.47GHz
The physical processor has 12 virtual processors (1 3 5 7 9 11 13 15 17 19 21 23)
x86 (chipid 0x1 GenuineIntel family 6 model 44 step 2 clock 3467 MHz)
Intel(r) Xeon(r) CPU X5690 @ 3.47GHz
$ /usr/sfw/bin/wget http://www.kernel.org/pub/linux/kernel/v3.0/linux-3.5.1.tar.bz2
--2012-08-12 17:09:38-- http://www.kernel.org/pub/linux/kernel/v3.0/linux-3.5.1.tar.bz2
Resolving www.kernel.org... 149.20.20.133, 149.20.4.69
Connecting to www.kernel.org|149.20.20.133|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 80981090 (77M) [application/x-bzip2]
Saving to: `linux-3.5.1.tar.bz2'
100%[======================================>] 80,981,090 605K/s in 2m 13s
$ ptime digest -a sha256 linux-3.5.1.tar.bz2
78f8553c7cbc09d9c12d45c7f6ec82f964bf35d324832bede2 73ba2f6fe3e3ed
real 0.552
user 0.496
sys 0.039
Strangely the openssl in Solaris 10 is SHA256 ignorant.
However one may use the mdigest in schilytools also :
$ ptime /opt/schily/bin/mdigest -a sha256 linux-3.5.1.tar.bz2
78f8553c7cbc09d9c12d45c7f6ec82f964bf35d324832bede2 73ba2f6fe3e3ed linux-3.5.1.tar.bz2
real 0.576
user 0.562
sys 0.014
Regardless .. let's do a test here :
$ mkdir foo
$ cd foo
$ ptime /opt/schily/bin/star -x -bz -xdir -xdot -U -fs=64m -fifostats -time file=../linux-3.5.1.tar.bz2
star: fifo had 46849 puts 80641 gets.
star: fifo was 14 times empty and 0 times full.
star: fifo held 22493696 bytes max, size was 67112960 bytes
star: fifo had 5 moves, total of 25600 moved bytes
star: fifo is 0% full (2k), size 65540k.
star: 46849 blocks + 0 bytes (total of 479733760 bytes = 468490.00k).
star: Total time 16.234sec (28858 kBytes/sec)
real 16.238
user 15.890
sys 3.738
There is also a GNU tar somewhere in Solaris 10 :
$ /usr/sfw/bin/gtar --version
tar (GNU tar) 1.26
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Written by John Gilmore and Jay Fenlason.
$ which bzip2
/usr/bin/bzip2
jupiter-sparc-SunOS5.10 # cat /etc/release
Solaris 10 5/08 s10s_u5wos_10 SPARC
Copyright 2008 Sun Microsystems, Inc. All Rights Reserved.
Use is subject to license terms.
Assembled 24 March 2008
jupiter-sparc-SunOS5.10 # psrinfo -pv
The physical processor has 1 virtual processor (0)
UltraSPARC-III+ (portid 0 impl 0x15 ver 0x23 clock 900 MHz)
The physical processor has 1 virtual processor (1)
UltraSPARC-III+ (portid 1 impl 0x15 ver 0x23 clock 900 MHz)
The physical processor has 1 virtual processor (2)
UltraSPARC-III+ (portid 2 impl 0x15 ver 0x23 clock 900 MHz)
The physical processor has 1 virtual processor (3)
UltraSPARC-III+ (portid 3 impl 0x15 ver 0x23 clock 900 MHz)
jupiter-sparc-SunOS5.10 # df -F ufs -h
Filesystem Size Used Available Capacity Mounted on
/dev/md/dsk/d0 16G 9.4G 6.2G 61% /
/dev/md/dsk/d3 7.8G 4.9G 2.6G 66% /var
jupiter-sparc-SunOS5.10 # pwd
/usr/local/src
jupiter-sparc-SunOS5.10 # ls -a
. ..
jupiter-sparc-SunOS5.10 # /usr/sfw/bin/wget http://www.kernel.org/pub/linux/kernel/v3.0/linux-3.5.1.tar.bz2
--2012-08-12 22:03:01-- http://www.kernel.org/pub/linux/kernel/v3.0/linux-3.5.1.tar.bz2
Resolving www.kernel.org... 149.20.20.133, 149.20.4.69
Connecting to www.kernel.org|149.20.20.133|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 80981090 (77M) [application/x-bzip2]
Saving to: `linux-3.5.1.tar.bz2'
jupiter-sparc-SunOS5.10 # ptime digest -a sha256 linux-3.5.1.tar.bz2
78f8553c7cbc09d9c12d45c7f6ec82f964bf35d324832bede2 73ba2f6fe3e3ed
real 3.699
user 3.286
sys 0.264
jupiter-sparc-SunOS5.10 # ptime /opt/schily/bin/mdigest -a sha256 linux-3.5.1.tar.bz2
78f8553c7cbc09d9c12d45c7f6ec82f964bf35d324832bede2 73ba2f6fe3e3ed linux-3.5.1.tar.bz2
real 3.136
user 2.964
sys 0.125
jupiter-sparc-SunOS5.10 # mkdir foo
jupiter-sparc-SunOS5.10 # cd foo
jupiter-sparc-SunOS5.10 # pwd
/usr/local/src/foo
jupiter-sparc-SunOS5.10 # ptime /opt/schily/bin/star -x -bz -xdir -xdot -U -fs=64m -fifostats -time file=../linux-3.5.1.tar.bz2
star: fifo had 46849 puts 80626 gets.
star: fifo was 1 times empty and 17 times full.
star: fifo held 67109888 bytes max, size was 67112960 bytes
star: fifo had 5 moves, total of 25600 moved bytes
star: fifo is 0% full (2k), size 65540k.
star: 46849 blocks + 0 bytes (total of 479733760 bytes = 468490.00k).
star: Total time 955.454sec (490 kBytes/sec)
real 15:55.612
user 1:01.947
sys 31.922
jupiter-sparc-SunOS5.10 # cd ..
jupiter-sparc-SunOS5.10 # ptime rm -rf foo
jupiter-sparc-SunOS5.10 # mkdir foo
jupiter-sparc-SunOS5.10 # cd foo
jupiter-sparc-SunOS5.10 # ptime /opt/schily/bin/star -x -xdir -xdot -U -fs=64m -fifostats -time file=../linux-3.5.1.tar
star: fifo had 46849 puts 80626 gets.
star: fifo was 1 times empty and 19 times full.
star: fifo held 67110912 bytes max, size was 67112960 bytes
star: fifo had 5 moves, total of 25600 moved bytes
star: fifo is 0% full (2k), size 65540k.
star: 46849 blocks + 0 bytes (total of 479733760 bytes = 468490.00k).
star: Total time 930.722sec (503 kBytes/sec)
compare zfs xfs and jfs o
