On Fri, Jan 1 at 21:21, Erik Trimble wrote:
That all said, it certainly would be really nice to get a SSD
controller which can really push the bandwidth, and the only way I
see this happening now is to go the stupid route, and dumb down the
controller as much as possible. I really think we
On 1 jan 2010, at 17.44, Richard Elling wrote:
On Dec 31, 2009, at 12:59 PM, Ragnar Sundblad wrote:
Flash SSDs actually always remap new writes into a
only-append-to-new-pages style, pretty much as ZFS does itself.
So for a SSD there is no big difference between ZFS and
filesystems as UFS,
On 1 jan 2010, at 17.28, David Magda wrote:
On Jan 1, 2010, at 11:04, Ragnar Sundblad wrote:
But that would only move the hardware specific and dependent flash
chip handling code into the file system code, wouldn't it? What
is won with that? As long as the flash chips have larger pages
Mike,
As far as I know only Hitachi is using such a huge chunk size :
So each vendor’s implementation of TP uses a different block size. HDS use
42MB on the USP, EMC use 768KB on DMX, IBM allow a variable size from 32KB to
256KB on the SVC and 3Par use blocks of just 16KB. The reasons for
Eric D. Mudama wrote:
On Fri, Jan 1 at 21:21, Erik Trimble wrote:
That all said, it certainly would be really nice to get a SSD
controller which can really push the bandwidth, and the only way I
see this happening now is to go the stupid route, and dumb down the
controller as much as
Ragnar Sundblad ra...@csc.kth.se wrote:
On 1 jan 2010, at 17.28, David Magda wrote:
Don't really see how things are either hardware specific or dependent.
The inner workings of a SSD flash drive is pretty hardware (or
rather vendor) specific, and it may not be a good idea to move
any
Ragnar Sundblad ra...@csc.kth.se wrote:
I certainly agree, but there still isn't much they can do about
the WORM-like properties of flash chips, were reading is pretty
fast, writing is not to bad, but erasing is very slow and must be
done in pretty large pages which also means that active
Joerg Schilling wrote:
Ragnar Sundblad ra...@csc.kth.se wrote:
On 1 jan 2010, at 17.28, David Magda wrote:
Don't really see how things are either hardware specific or dependent.
The inner workings of a SSD flash drive is pretty hardware (or
rather vendor) specific, and it
If pool isnt rpool you might to want to boot into singleuser mode (-s after
kernel parameters on boot) remove /etc/zfs/zpool.cache and then reboot.
after that you can merely ssh into box and watch iostat while import.
Yours
Markus Kovero
___
switched to another system, RAM 4Gb - 16Gb
the importing process lasts about 18hrs now
the system is responsive
if developers want it I may provide ssh access
I have no critical data there, it is an acceptance test only
--
This message posted from opensolaris.org
Erik Trimble erik.trim...@sun.com wrote:
From ZFS's standpoint, the optimal configuration would be for the SSD
to inform ZFS as to it's PAGE size, and ZFS would use this as the
fundamental BLOCK size for that device (i.e. all writes are in integer
It seems that a command to retrieve this
I'm moving from FreeBSD to OpenSolaris in the next week or so (when the rest
of my upgrade purchase arrives)
One thing i'm curious about is whether or not ZFS cares about changing
device names.
In FreeBSD I always used glabel to prevent this issue. Does solaris have
something similar? Is it
On Sat, Jan 2, 2010 at 7:40 AM, Thomas Burgess wonsl...@gmail.com wrote:
I'm moving from FreeBSD to OpenSolaris in the next week or so (when the
rest of my upgrade purchase arrives)
One thing i'm curious about is whether or not ZFS cares about changing
device names.
In FreeBSD I always
On 2 jan 2010, at 12.43, Joerg Schilling wrote:
Ragnar Sundblad ra...@csc.kth.se wrote:
I certainly agree, but there still isn't much they can do about
the WORM-like properties of flash chips, were reading is pretty
fast, writing is not to bad, but erasing is very slow and must be
done in
On 2 jan 2010, at 13.10, Erik Trimble wrote:
Joerg Schilling wrote:
Ragnar Sundblad ra...@csc.kth.se wrote:
On 1 jan 2010, at 17.28, David Magda wrote:
Don't really see how things are either hardware specific or dependent.
The inner workings of a SSD flash drive is
On Sat, 2 Jan 2010, Tim Cook wrote:
Nope, on import it will scan all the disks for ZFS pools. It
doesn't care about the physical device names changing.
It does seem to care after the pool has been imported. A few people
have been bit by hardware/BIOS/firmware updates which somehow changes
On Sat, Jan 2, 2010 at 12:25 PM, Bob Friesenhahn
bfrie...@simple.dallas.tx.us wrote:
On Sat, 2 Jan 2010, Tim Cook wrote:
Nope, on import it will scan all the disks for ZFS pools. It doesn't care
about the physical device names changing.
It does seem to care after the pool has been
Thanks for this thread! I was just coming here to discuss this very same
problem. I'm running 2009.06 on a Q6600 with 8GB of RAM. I have a Windows
system writing multiple OTA HD video streams via CIFS to the 2009.06 system
running Samba.
I then have multiple clients reading back other HD
Richard Elling wrote:
Perhaps I am not being clear. If a disk is really dead, then
there are several different failure modes that can be responsible.
For example, if a disk does not respond to selection, then it
is diagnosed as failed very quickly. But that is not the TLER
case. The TLER
On Sat, Jan 2, 2010 at 13:10, Markus Kovero markus.kov...@nebula.fi wrote:
If pool isnt rpool you might to want to boot into singleuser mode (-s after
kernel parameters on boot) remove /etc/zfs/zpool.cache and then reboot.
after that you can merely ssh into box and watch iostat while import.
If pool isnt rpool you might to want to boot into
singleuser mode (-s after kernel parameters on boot)
remove /etc/zfs/zpool.cache and then reboot.
after that you can merely ssh into box and watch
iostat while import.
Yours
Markus Kovero
___
That's the thing, the drive lights aren't blinking,
but I was thinking maybe the writes are going so slow
that it's possible they aren't registering. And since
I can't keep a running iostat, Ican't tell if
anything is going on. I can however get into the
KMDB. is there something in there
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Be sure to also update to the latest dev b130 release, as that also
helps with a more smooth scheduling class for the zfs threads. If the
upgrade breaks anything, you can always just boot back into the old
environment before the upgrade.
Regards,
-
Joerg Schilling wrote:
Erik Trimble erik.trim...@sun.com wrote:
From ZFS's standpoint, the optimal configuration would be for the SSD
to inform ZFS as to it's PAGE size, and ZFS would use this as the
fundamental BLOCK size for that device (i.e. all writes are in integer
It seems
Ragnar Sundblad wrote:
On 2 jan 2010, at 13.10, Erik Trimble wrote
Joerg Schilling wrote:
the TRIM command is what is intended for an OS to notify the SSD as to which blocks are deleted/erased, so the SSD's internal free list can be updated (that is, it allows formerly-in-use blocks to be
Hey Markus,
Thanks for the suggestion, but as stated in the thread, I am booting using
-s -kv -m
verbose and deleting the cache file was one of the first troubleshooting
steps we and
the others affected did.The other problem is that we were all starting an
iostat at
the
On Fri, Jan 1, 2010 at 8:31 PM, Erik Trimble erik.trim...@sun.com wrote:
Bob Friesenhahn wrote:
On Fri, 1 Jan 2010, Al Hopper wrote:
Interesting article - rumor has it that this is the same controller
that Seagate will use in its upcoming enterprise level SSDs:
Tim Cook wrote:
While I'm sure to offend someone, it must be stated. That's not going
to happen for the simple fact that there's all of two vendors that
could utilize it, both niche (in relative terms). NetApp and Sun.
Why would SSD MFG's waste their time building drives to sell for less
On 2 jan 2010, at 22.49, Erik Trimble wrote:
Ragnar Sundblad wrote:
On 2 jan 2010, at 13.10, Erik Trimble wrote
Joerg Schilling wrote:
the TRIM command is what is intended for an OS to notify the SSD as to
which blocks are deleted/erased, so the SSD's internal free list can be
updated
On Jan 2, 2010, at 19:44, Erik Trimble wrote:
I do think the market is slight larger: Hitachi and EMC storage
arrays/big SAN controllers, plus all Linux boxes once Brtfs
actually matures enough to be usable. I don't see MSFT making any
NTFS changes to help here, but they are doing some
On Sat, Jan 2, 2010 at 5:40 PM, Tim Cook t...@cook.ms wrote:
On Fri, Jan 1, 2010 at 8:31 PM, Erik Trimble erik.trim...@sun.com wrote:
Bob Friesenhahn wrote:
On Fri, 1 Jan 2010, Al Hopper wrote:
Interesting article - rumor has it that this is the same controller
that Seagate will use in
On Sat, 2 Jan 2010, David Magda wrote:
Apple is (sadly?) probably developing their own new file system as well.
I assume that you are talking about developing a filesystem design
more suitable for the iNetbook and the iPhone?
Hardly any Apple users are complaining about the advanced
On Saturday, January 2, 2010, Bob Friesenhahn
bfrie...@simple.dallas.tx.us wrote:
On Sat, 2 Jan 2010, David Magda wrote:
Apple is (sadly?) probably developing their own new file system as well.
I assume that you are talking about developing a filesystem design more
suitable for the
On Jan 2, 2010, at 20:51, Tim Cook wrote:
Apple users not complaining is more proof of them having
not only drunk the koolaid but also bathed in it than them knowing any
lImtations of what they have today. This coming from someone with a
MacBook pro sitting in the other room.
Apple users not
On Jan 2, 2010, at 16:49, Erik Trimble wrote:
My argument is that the OS has a far better view of the whole data
picture, and access to much higher performing caches (i.e. RAM/
registers) than the SSD, so not only can the OS make far better
decisions about the data and how (and how much of)
On Jan 2, 2010, at 1:47 AM, Andras Spitzer wrote:
Mike,
As far as I know only Hitachi is using such a huge chunk size :
So each vendor’s implementation of TP uses a different block size.
HDS use 42MB on the USP, EMC use 768KB on DMX, IBM allow a variable
size from 32KB to 256KB on the SVC
Ragnar Sundblad wrote:
On 2 jan 2010, at 22.49, Erik Trimble wrote:
Ragnar Sundblad wrote:
On 2 jan 2010, at 13.10, Erik Trimble wrote
Joerg Schilling wrote:
the TRIM command is what is intended for an OS to notify the SSD as to which
blocks are deleted/erased, so the
David Magda wrote:
On Jan 2, 2010, at 16:49, Erik Trimble wrote:
My argument is that the OS has a far better view of the whole data
picture, and access to much higher performing caches (i.e.
RAM/registers) than the SSD, so not only can the OS make far better
decisions about the data and how
On Sat, Jan 2, 2010 at 9:45 PM, David Magda dma...@ee.ryerson.ca wrote:
On Jan 2, 2010, at 20:51, Tim Cook wrote:
Apple users not complaining is more proof of them having
not only drunk the koolaid but also bathed in it than them knowing any
lImtations of what they have today. This coming
-Original Message-
From: Ross Walker [mailto:rswwal...@gmail.com]
Sent: Thu 12/31/2009 12:35 AM
To: Steffen Plotner
Cc: zfs-discuss@opensolaris.org
Subject: Re: [zfs-discuss] zvol (slow) vs file (fast) performance snv_130
Been there.
ZVOLs were changed a while ago to make each operation
On 3 jan 2010, at 04.19, Erik Trimble wrote:
Ragnar Sundblad wrote:
On 2 jan 2010, at 22.49, Erik Trimble wrote:
Ragnar Sundblad wrote:
On 2 jan 2010, at 13.10, Erik Trimble wrote
Joerg Schilling wrote:
the TRIM command is what is intended for an OS to notify the SSD as
On 3 jan 2010, at 06.07, Ragnar Sundblad wrote:
(I don't think they typically merge pages, I believe they rather
just pick pages with some freed blocks, copies the active blocks
to the end of the disk, and erases the page.)
(And of course you implement wear leveling with the same
mechanism -
Ragnar Sundblad wrote:
On 3 jan 2010, at 04.19, Erik Trimble wrote:
Let's say I have 4k blocks, grouped into a 128k page. That is, the SSD's
fundamental minimum unit size is 4k, but the minimum WRITE size is 128k. Thus,
32 blocks in a page.
Do you know of SSD disks that have a
Erik Trimble wrote:
Ragnar Sundblad wrote:
Yes, there is something to worry about, as you can only
erase flash in large pages - you can not erase them only where
the free data blocks in the Free List are.
I'm not sure that SSDs actually _have_ to erase - they just overwrite
anything there
On Wed, Dec 30, 2009 at 9:35 PM, Ross Walker rswwal...@gmail.com wrote:
On Dec 30, 2009, at 11:55 PM, Steffen Plotner swplot...@amherst.edu
wrote:
Hello,
I was doing performance testing, validating zvol performance in
particularly, and found that zvol write performance to be slow ~35-44MB/s
45 matches
Mail list logo
