In message <4b6a0db0.3000...@bogus.com>, Joel Jaeggli writes:
>Actaully wear leveling on the part of the disk controller should if
>implemented properly work even if the disk is both fully or nearly so
>committed and unaware of block utilization.
If by "work" you mean "allow blocks to get writte
Jordan Share wrote:
> On 2/3/2010 1:21 PM, Poul-Henning Kamp wrote:
>> In message<4b69cd90.8080...@krotus.com>, Jordan Share writes:
>>> On 2/3/2010 6:18 AM, Poul-Henning Kamp wrote: Well, you can
>>> always partition the disk in half, and literally never write to
>>> the "last half" of the disk
In message , "Martin K. Petersen" writes:
>The mind boggles at the disingenuity of the FTL in many of these SSDs.
The problem is the M-Systems patents which Sandisk have sued the
world & its dog for: either you pay, or you make some crap.
Only Intel avoids paying, because Sandisk likes to be abl
> "phk" == Poul-Henning Kamp writes:
phk> In message <4b6a03d9.10...@krotus.com>, Jordan Share writes:
>> Yes, and after a "secure erase" command (and, presumably, fresh from
>> the factory), the FAL does know that there is no good data on the
>> disk, right? (As mentioned here:
>> http://ww
In message <4b6a03d9.10...@krotus.com>, Jordan Share writes:
>Yes, and after a "secure erase" command (and, presumably, fresh
>from the factory), the FAL does know that there is no good data on
>the disk, right? (As mentioned here:
>http://www.anandtech.com/storage/showdoc.aspx?i=3531&p=11 )
My
On 2/3/2010 1:21 PM, Poul-Henning Kamp wrote:
> In message<4b69cd90.8080...@krotus.com>, Jordan Share writes:
>> On 2/3/2010 6:18 AM, Poul-Henning Kamp wrote:
>
>> Well, you can always partition the disk in half, and literally
>> never write to the "last half" of the disk (which is what I thought
>
In message <4b69cd90.8080...@krotus.com>, Jordan Share writes:
>On 2/3/2010 6:18 AM, Poul-Henning Kamp wrote:
>Well, you can always partition the disk in half, and literally
>never write to the "last half" of the disk (which is what I thought
>Bob to be suggesting in his post).
Again, that only w
On 2/3/2010 6:18 AM, Poul-Henning Kamp wrote:
> In message, Bob Camp writes:
>> Hi
>>
>> If half the disk is un-used, there's a *lot* of space to move the directory
>> sectors off to as they wear ...
>
> Yeah, well, only if the Flash-Adaptation-Layer *know* they are unused.
>
> That is why you nee
In message <100485b24adb4babb9aa2975ce67a...@vectron.com>, "Bob Camp" writes:
>. bringing us full circle to the original question about the TRIM
>command's full integration into FreeBSD at the file system level.
Exactly.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.o
ry 03, 2010 9:18 AM
To: Bob Camp
Cc: soekris-tech@lists.soekris.com
Subject: Re: [Soekris] Soekris 5501 with SSD disks
In message , Bob Camp writes:
>Hi
>
>If half the disk is un-used, there's a *lot* of space to move the directory
sectors off to as they wear ...
Yeah, well, only if t
In message , Bob Camp writes:
>Hi
>
>If half the disk is un-used, there's a *lot* of space to move the directory
>sectors off to as they wear ...
Yeah, well, only if the Flash-Adaptation-Layer *know* they are unused.
That is why you need to tell Flash drives when you delete files, that the
conte
Hi
If half the disk is un-used, there's a *lot* of space to move the directory
sectors off to as they wear ...
>From past experience frying these parts (been there done that), the magic
>"failure" point is simply time it takes the average cell to hit a certain bit
>error rate. Some get further
Howdy,
If you are careful to not do more than one write to each sector per
day, you should make it. An MLC cell should take 1 writes. 20
years is 7305 days, so there is no room for 2 writes per day.
If you write to a normal filesystem, the directory sectors are not
going to survive. Even
Hi
If I can re-write the entire disk once a day for 20 years, that's good enough
for what I'm doing.
Bob
On Feb 2, 2010, at 2:37 PM, Ralph Green wrote:
> On Tue, 2010-02-02 at 07:41 -0500, Bob Camp wrote:
>
>> Next up is price. I'm seeing a 3 to 5X premium for the SLC's. That's a big
>> ju
On Tue, 2010-02-02 at 07:41 -0500, Bob Camp wrote:
> Next up is price. I'm seeing a 3 to 5X premium for the SLC's. That's a big
> jump,
This is why MLC is so widespread. There is a big difference in cost to
manufacture. The actual cost is 2 to 4 times more for SLC.
> The question becomes -
Hi
At least with SSD's the MLC's outnumber the SLC's by a very wide margin. Where
I shop it's at least 30:1 in favor of the MLC's. That can put you into a "Joe
No Name SLC" vs a brand name MLC decision.
Next up is price. I'm seeing a 3 to 5X premium for the SLC's. That's a big
jump, and it's
On Sun, Jan 31, 2010 at 01:59:47PM -0700, David Alexander wrote:
> On Sat, 30 Jan 2010 08:50:09 +, "Poul-Henning Kamp"
> wrote:
>
> >In message <3f8f34c5-f376-46b0-9e2c-53a213d0e...@cq.nu>, Bob Camp writes:
> >
> >>> Don't get an SSD thinking you're going to get speed. The 5501 will
> >>> li
> "David" == David Alexander writes:
David> Yes it does. I should have mentioned that the one thing that
David> drove me to buy the SSD was how poorly my CF card handled
David> multiple simultaneous requests. For example, when I open my
David> email client it syncs all the folders with the
On Sat, 30 Jan 2010 08:50:09 +, "Poul-Henning Kamp"
wrote:
>In message <3f8f34c5-f376-46b0-9e2c-53a213d0e...@cq.nu>, Bob Camp writes:
>
>>> Don't get an SSD thinking you're going to get speed. The 5501 will
>>> limit the throughput well below what you'd expect for an SSD.
>
>An SSD still do
In message <3f8f34c5-f376-46b0-9e2c-53a213d0e...@cq.nu>, Bob Camp writes:
>> Don't get an SSD thinking you're going to get speed. The 5501 will
>> limit the throughput well below what you'd expect for an SSD.
An SSD still does miracles for access time.
--
Poul-Henning Kamp | UNIX since
Hi
At least as I understand it:
Properly done with TRIM, the file system lets the disk know each time a file
is deleted and space is now empty.
With garbage collection, the never used sectors are accumulated together to
make erase and re-write faster.
To some extent they are complementary o
On Wed, 27 Jan 2010 20:24:03 +0100, Joel Dahl
wrote:
>So, is anyone running a Soekris 5501 with a SSD disk? I'm looking at buying a
>couple of 5501's and equip them with Intel X25-M disks, so if anyone have any
>experience with this type of configuration I'd be interested to hear your
>thought
N.J. Mann writes answers Bob Camp:
>> Now if we could just get the TRIM command implemented in a FreeBSD.
>
> http://svn.freebsd.org/viewvc/base?view=revision&revision=201139
Linux does it too in 2.6.33, and unlink() on an ext4fs causes trim
eventually, so that makes it three evil OSes. (Wil
In message <7781c524-a76d-4772-9f1a-9c032f48e...@cq.nu>,
Bob Camp (soek...@cq.nu) wrote:
>
[...]
>
> Now if we could just get the TRIM command implemented in a
> FreeBSD.
http://svn.freebsd.org/viewvc/base?view=revision&revision=201139
Cheers,
Nick.
--
___
Hi
Nothing wrong with FreeBSD. Nothing wrong with the 5501. Nothing wrong with the
disk you have chosen.
There are some disks out there than do have issues. Apparently they aren't very
efficient at handling the disk as it fills up.
Now if we could just get the TRIM command implemented in a Fr
In message , Joel Dahl writes
:
>So, is anyone running a Soekris 5501 with a SSD disk?
Yes, I've been running with an MTRON 32GB device for over a year.
Nothing much to report, it works...
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
So, is anyone running a Soekris 5501 with a SSD disk? I'm looking at buying a
couple of 5501's and equip them with Intel X25-M disks, so if anyone have any
experience with this type of configuration I'd be interested to hear your
thoughts. Any problems I should be aware of? I'll probably run Fre
27 matches
Mail list logo
