So ZFS isn't state-of-the-art?
Of course it's state-of-the-art (on Solaris ;-) )
WAFL is for high-turnover filesystems on RAID-5 (and assumes flash memory
staging areas).
s/RAID-5/RAID-4/
Not your run-of-the-mill desktop...
The WAFL-Thing was just a joke ;-)
Regards,
Adrian
suspect, particularly with 7200/min (s)ATA crap.
Quoting myself (again):
A quick'n'dirty ZFS-vs-UFS-vs-Reiser3-vs-Reiser4-vs-Ext3 'benchmark'
Yeah, the test ran on a single SATA-Harddisk (quick'n'dirty).
I'm so sorry but i don't have access to a $$$ Raid-System at home.
Anyway: The test
Adrian Ulrich schrieb am 2006-08-01:
suspect, particularly with 7200/min (s)ATA crap.
Quoting myself (again):
A quick'n'dirty ZFS-vs-UFS-vs-Reiser3-vs-Reiser4-vs-Ext3 'benchmark'
Yeah, the test ran on a single SATA-Harddisk (quick'n'dirty).
I'm so sorry but i don't have access to a
Matthias Andree wrote:
No, it is valid to run the test on commodity hardware, but if you (or
the benchmark rather) is claiming transactions, I tend to think
ACID, and I highly doubt any 200 GB SATA drive manages 3000
synchronous writes per second without causing either serious
fragmentation or
I didn't mean to say your particular drive were crap, but 200GB SATA
drives are low end, like it or not --
And you think an 18 GB SCSI disk just does it better because it's SCSI?
Esp. in long sequential reads.
Jan Engelhardt
--
Jan Engelhardt schrieb am 2006-08-01:
I didn't mean to say your particular drive were crap, but 200GB SATA
drives are low end, like it or not --
And you think an 18 GB SCSI disk just does it better because it's SCSI?
18 GB SCSI disks are 1999 gear, so who cares?
Seagate didn't sell 200 GB
I didn't mean to say your particular drive were crap, but 200GB SATA
drives are low end, like it or not --
And you think an 18 GB SCSI disk just does it better because it's SCSI?
18 GB SCSI disks are 1999 gear, so who cares?
Seagate didn't sell 200 GB SATA drives at that time.
Esp. in long
Adrian Ulrich [EMAIL PROTECTED] wrote:
[...]
ZFS uses 'dnodes'. The dnodes are allocated on demand from your
available space so running out of [di]nodes is impossible.
Great to see that Sun ships a state-of-the-art Filesystem with
Solaris... I think linux should do the same...
This would
On 31-Jul-06, at 11:18 PM, Horst H. von Brand wrote:
Adrian Ulrich [EMAIL PROTECTED] wrote:
[...]
ZFS uses 'dnodes'. The dnodes are allocated on demand from your
available space so running out of [di]nodes is impossible.
Great to see that Sun ships a state-of-the-art Filesystem with
Great to see that Sun ships a state-of-the-art Filesystem with
Solaris... I think linux should do the same...
This would be worthwhile, if only to be able to futz around in Solaris-made
filesystems.
s/I think linux should do the same/I think linux should include Reiser4/
;-)
First
Adrian Ulrich wrote:
See also: http://spam.workaround.ch/dull/postmark.txt
A quick'n'dirty ZFS-vs-UFS-vs-Reiser3-vs-Reiser4-vs-Ext3 'benchmark'
Whatever Postmark does, this looks pretty besides the point.
Are these actual transactions with the Durability guarantee?
3000/s doesn't look too
Adrian Ulrich [EMAIL PROTECTED] wrote:
Great to see that Sun ships a state-of-the-art Filesystem with
Solaris... I think linux should do the same...
This would be worthwhile, if only to be able to futz around in Solaris-made
filesystems.
s/I think linux should do the same/I think
On 7/31/06, Matthias Andree [EMAIL PROTECTED] wrote:
Adrian Ulrich wrote:
See also: http://spam.workaround.ch/dull/postmark.txt
A quick'n'dirty ZFS-vs-UFS-vs-Reiser3-vs-Reiser4-vs-Ext3 'benchmark'
Whatever Postmark does, this looks pretty besides the point.
why's that? postmark is one of
On 7/31/06, Horst H. von Brand [EMAIL PROTECTED] wrote:
Adrian Ulrich [EMAIL PROTECTED] wrote:
Great to see that Sun ships a state-of-the-art Filesystem with
Solaris... I think linux should do the same...
This would be worthwhile, if only to be able to futz around in Solaris-made
On Mon, 31 Jul 2006, Nate Diller wrote:
On 7/31/06, Matthias Andree [EMAIL PROTECTED] wrote:
Adrian Ulrich wrote:
See also: http://spam.workaround.ch/dull/postmark.txt
A quick'n'dirty ZFS-vs-UFS-vs-Reiser3-vs-Reiser4-vs-Ext3 'benchmark'
Whatever Postmark does, this looks pretty besides
On 7/31/06, David Lang [EMAIL PROTECTED] wrote:
On Mon, 31 Jul 2006, Nate Diller wrote:
On 7/31/06, Matthias Andree [EMAIL PROTECTED] wrote:
Adrian Ulrich wrote:
See also: http://spam.workaround.ch/dull/postmark.txt
A quick'n'dirty ZFS-vs-UFS-vs-Reiser3-vs-Reiser4-vs-Ext3 'benchmark'
On Mon, 31 Jul 2006, Nate Diller wrote:
On 7/31/06, David Lang [EMAIL PROTECTED] wrote:
On Mon, 31 Jul 2006, Nate Diller wrote:
On 7/31/06, Matthias Andree [EMAIL PROTECTED] wrote:
Adrian Ulrich wrote:
See also: http://spam.workaround.ch/dull/postmark.txt
A quick'n'dirty
On 7/31/06, David Lang [EMAIL PROTECTED] wrote:
On Mon, 31 Jul 2006, Nate Diller wrote:
On 7/31/06, David Lang [EMAIL PROTECTED] wrote:
On Mon, 31 Jul 2006, Nate Diller wrote:
On 7/31/06, Matthias Andree [EMAIL PROTECTED] wrote:
Adrian Ulrich wrote:
See also:
On Mon, 31 Jul 2006, Nate Diller wrote:
this is only a limitation for filesystems which do in-place data and
metadata updates. this is why i mentioned the similarities to log
file systems (see rosenblum and ousterhout, 1991). they observed an
order-of-magnitude increase in performance for
On 7/31/06, Matthias Andree [EMAIL PROTECTED] wrote:
On Mon, 31 Jul 2006, Nate Diller wrote:
this is only a limitation for filesystems which do in-place data and
metadata updates. this is why i mentioned the similarities to log
file systems (see rosenblum and ousterhout, 1991). they
Matthias Andree wrote:
On Mon, 31 Jul 2006, Nate Diller wrote:
this is only a limitation for filesystems which do in-place data and
metadata updates. this is why i mentioned the similarities to log
file systems (see rosenblum and ousterhout, 1991). they observed an
order-of-magnitude
On Mon, Jul 31, 2006 at 08:31:32PM -0500, David Masover wrote:
So you use a repacker. Nice thing about a repacker is, everyone has
downtime. Better to plan to be a little sluggish when you'll have
1/10th or 1/50th of the users than be MUCH slower all the time.
Actually, that's a problem
Theodore Tso wrote:
On Mon, Jul 31, 2006 at 08:31:32PM -0500, David Masover wrote:
So you use a repacker. Nice thing about a repacker is, everyone has
downtime. Better to plan to be a little sluggish when you'll have
1/10th or 1/50th of the users than be MUCH slower all the time.
Actually,
Different users have different needs.
I agree, there are many users who can not afford any
downtime.
I worked at the NYSE and they reboot all their
computers once a week. We had a policy at NYSE. If
you suspect a computer has hardware problems, take it
off line. It is better to be short a few
Timothy Webster wrote:
Different users have different needs.
I'm having trouble thinking of users who need an FS that doesn't need a
repacker.
The disk error problem, though, you're right -- most users will have to
get bitten by this, hard, at least once, or they'll never get the
On Mon, 2006-07-31 at 23:00 -0400, Theodore Tso wrote:
The problem is that many benchmarks (such as taring and untaring the
kernel sources in reiser4 sort order) are overly simplistic, in that
they don't really reflect how people use the filesystem in real life.
(How many times can you
26 matches
Mail list logo
