On Tue, 20 Apr 2010 16:22:32 -0500 Marco Peereboom sl...@peereboom.us
wrote:
On Tue, Apr 20, 2010 at 03:01:58PM -0500, Marco Peereboom wrote:
On Tue, Apr 20, 2010 at 03:48:23PM -0400, Ted Unangst wrote:
On Tue, Apr 20, 2010 at 3:11 PM, Marco Peereboom
sl...@peereboom.us wrote:
And
On Tue, Apr 20, 2010 at 1:52 PM, Chris Dukes pak...@pr.neotoma.org wrote:
Just rethink your deployment strategy to not use 'dd'.
Even Windows cloning systems stopped trying to copy all bits
on the disk 6+ years ago.
'dd' made some sense when the disk was mostly full and there was
a huge
On Tue, Apr 20, 2010 at 11:03:30PM -0700, J.C. Roberts wrote:
degrade. You might be better off in the long run using multiple
rotating disks that are half as fast, and half the price, but won't
degrade.
It's my understanding that if you have a decent SSD, write response times
can (under some
Daniel Barowy [dbar...@barowy.net] wrote:
The problem is that we're copying the entire disk, so, as far as the
disk (i.e., SSDs) is aware, that disk is 100% full-- all blocks are
To make your deployment faster, just use fdisk, disklabel, newfs to setup the
disk and tar to copy the files.
On Wed, 21 Apr 2010, Chris Cappuccio wrote:
To make your deployment faster, just use fdisk, disklabel, newfs to setup the
disk and tar to copy the files. That's a much smarter/faster way to go, even
with TRIM support. I automated it in 'growimg' for flashdist/flashrd, for
instance. Of
On Wed, Apr 21, 2010 at 01:52:58PM -0400, Daniel Barowy wrote:
The reality is that our novice administrators rarely do any real
server deployment-- it's really just me and another guy-- so when it
comes down to it, this is just a time-saving measure for us. The
genesis of it was from doing
On 2010-04-21, Daniel Barowy dbar...@barowy.net wrote:
On Wed, 21 Apr 2010, Chris Cappuccio wrote:
To make your deployment faster, just use fdisk, disklabel, newfs to setup
the disk and tar to copy the files. That's a much smarter/faster way to go,
even with TRIM support. I automated it
On Wed, 21 Apr 2010 18:40:10 +0200 Jurjen Oskam jur...@stupendous.org
wrote:
On Tue, Apr 20, 2010 at 11:03:30PM -0700, J.C. Roberts wrote:
degrade. You might be better off in the long run using multiple
rotating disks that are half as fast, and half the price, but won't
degrade.
It's
What problem are you trying to solve?
And no, TRIM isn't supported.
On Tue, Apr 20, 2010 at 01:58:30PM -0400, Daniel Barowy wrote:
Hello,
Anyone know the status/plans of TRIM support in OpenBSD? I poked
around a bit in ahci.c and scsi.c, but nothing pops out at me (I also
don't really
On Tue, 20 Apr 2010, Marco Peereboom wrote:
What problem are you trying to solve?
And no, TRIM isn't supported.
My concern is the procedure we've been using to deploy OpenBSD machines.
We set up a base machine with a standard disk layout, utilities, admin
account, etc... and then make a
On Tue, Apr 20, 2010 at 02:56:11PM -0400, Daniel Barowy wrote:
On Tue, 20 Apr 2010, Marco Peereboom wrote:
What problem are you trying to solve?
And no, TRIM isn't supported.
My concern is the procedure we've been using to deploy OpenBSD machines.
We set up a base machine with a
On Tue, Apr 20, 2010 at 3:11 PM, Marco Peereboom sl...@peereboom.us wrote:
And no, TRIM isn't supported.
The problem is that we're copying the entire disk, so, as far as the disk
(i.e., SSDs) is aware, that disk is 100% full-- all blocks are marked as
used even if they're empty. If I
On Tue, Apr 20, 2010 at 02:56:11PM -0400, Daniel Barowy wrote:
The problem is that we're copying the entire disk, so, as far as the
disk (i.e., SSDs) is aware, that disk is 100% full-- all blocks are
marked as used even if they're empty. If I understand correctly,
how the controller
On Tue, Apr 20, 2010 at 03:48:23PM -0400, Ted Unangst wrote:
On Tue, Apr 20, 2010 at 3:11 PM, Marco Peereboom sl...@peereboom.us wrote:
And no, TRIM isn't supported.
The problem is that we're copying the entire disk, so, as far as the disk
(i.e., SSDs) is aware, that disk is 100% full--
On Tue, 20 Apr 2010, Ted Unangst wrote:
It's not about writing too often, it's about the performance hit doing
a read/modify/write when there's no free blocks. Like the 4k sector
problem, but potentially even worse.
On the other hand, it depends on how much writing your server will do
in
On Tue, Apr 20, 2010 at 03:01:58PM -0500, Marco Peereboom wrote:
On Tue, Apr 20, 2010 at 03:48:23PM -0400, Ted Unangst wrote:
On Tue, Apr 20, 2010 at 3:11 PM, Marco Peereboom sl...@peereboom.us wrote:
And no, TRIM isn't supported.
The problem is that we're copying the entire disk, so,
On 21/04/2010, at 3:58 AM, Daniel Barowy wrote:
Hello,
Anyone know the status/plans of TRIM support in OpenBSD? I poked around a
bit in ahci.c and scsi.c, but nothing pops out at me (I also don't really know
what I'm looking for).
the status of TRIM support is that there is none.
i have no
On Tue, Apr 20, 2010 at 19:51, David Gwynne l...@animata.net wrote:
On 21/04/2010, at 3:58 AM, Daniel Barowy wrote:
Hello,
B Anyone know the status/plans of TRIM support in OpenBSD? B I poked around
a
bit in ahci.c and scsi.c, but nothing pops out at me (I also don't really
know
what I'm
18 matches
Mail list logo
