Openbsd Mail Box: Re: Add Support For Mac
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 copy of the entire disk using dd. We save this on our SAN, and when we want a new machine, simply pull a disk off the shelf, copy the image to the disk, boot, then customize. 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 handles block reallocation in this scenario depends how it is implemented in the disk's firmware, with some being better than others. At present, we have Intel X25-E disks. So, if the above is correct, then I will need to either rethink our deployment strategy (like, always leave some spae on the disk, untouched by dd), or else try not to write so often (like, using a ramdisk). I could also be overestimating the importance of all of this. On Tue, 20 Apr 2010, Marco Peereboom wrote: What problem are you trying to solve?
Openbsd Mailbox Re Add Support For Mac Os X
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 copy of the entire disk using dd. We save this on our SAN, and when we want a new machine, simply pull a disk off the shelf, copy the image to the disk, boot, then customize. 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 handles block reallocation in this scenario depends how it is implemented in the disk's firmware, with some being better than others.
At present, we have Intel X25-E disks. So, if the above is correct, then I will need to either rethink our deployment strategy (like, always leave some spae on the disk, untouched by dd), or else try not to write so often (like, using a ramdisk). I could also be overestimating the importance of all of this.
The whole not write so often is really really really uninteresting. ThanksDan.
On Tue, Apr 20, 2010 at 3:11 PM, Marco Peereboom 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 understand correctly, how the controller handles block reallocation in this scenario depends how it is You are. The whole not write so often is really really really uninteresting. 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 service.
If you aren't writing large files, you won't notice much difference, and the benefit of ultra fast random access is more than worth it. 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 correctlyhow the controller handles block reallocation in this scenario depends how it is implemented in the disk's firmware, with some being better than others. At present, we have Intel X25-E disks. Err, just how frequently are you doing this? The answer is going to change a bit if you're doing this infrequently vs. Doing this as a part of manufacturing turn key boxes. I am going to assume the former, not the latter. If you don't want as many blocks to appear as used, write to fewer blocks.
IE partition it, slice it, mkfs it, and restore from a tarball. You can even put your gzipped tarball of the base system where the installer expects to find base##.tgz and tell it to only install your tarball. So, if the above is correct, then I will need to either rethink our deployment strategy (like, always leave some spae on the diskuntouched by dd), or else try not to write so often (like, using a ramdisk). I could also be overestimating the importance of all of this.
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 penalty to keep seeking between data and metadata. 'dd' continues to make sense if you need to make a copy of everything before attempting to recover data or metadata. Chris Dukes.
On Tue, Apr 20, 2010 at 3:11 PM, Marco Peereboom 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.
Openbsd Mail Box: Re: Add Support For Mac Pro
If I understand correctly, how the controller handles block reallocation in this scenario depends how it is You are. The whole not write so often is really really really uninteresting. 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 service. If you aren't writing large files, you won't notice much difference, and the benefit of ultra fast random access is more than worth it.
I am 100% unconvinced. 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 service.
If you aren't writing large files, you won't notice much difference, and the benefit of ultra fast random access is more than worth it. Right now, the machines I am working on are mail gateways. They'll need to do frequent small writes as mail is shuffled between various queues. As long as we keep up with incoming mail, we're fine- this is less of an issue now that spamd turns away most connections before they submit any data for processing.
We were looking for a general answer, though, since the same strategy is used to deploy machines for other purposes (databases, web servers, routers, etc), although any application that requires lots of storage will probably get a big disk (or more likely, NFS to a big disk) specifically for that purpose. Thanks for the answers, everyone. I have some good ideas to look into. On Tue, Apr 20, 2010 at 03:48:23PM -0400, Ted Unangst wrote: On Tue, Apr 20, 2010 at 3:11 PM, Marco Peereboom 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 understand correctly, how the controller handles block reallocation in this scenario depends how it is You are. The whole not write so often is really really really uninteresting. 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 service. If you aren't writing large files, you won't notice much difference, and the benefit of ultra fast random access is more than worth it. I am 100% unconvinced. I.was. 100% unconvinced. I am much better educated now.
Yes this could be neat:-). On, at 3:58 AM, Daniel Barowy wrote: HelloAnyone 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 plans currently, though that could change if i ever get gear that would make good use of it. Tweaking the scsi and atascsi layers to support unmap and trim is simple, but making the block and fs layers make use of it would be 'interesting'. 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 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 understand correctly, how the controller handles block reallocation in this scenario depends how it is You are. The whole not write so often is really really really uninteresting. 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 service.
If you aren't writing large files, you won't notice much difference, and the benefit of ultra fast random access is more than worth it. I am 100% unconvinced. I.was.
100% unconvinced. I am much better educated now. Yes this could be neat:-) Heck, that didn't take long.;) The impact of read/modify/write can be significant on SSD's, and performance of these devices degrades over time/use. The percent of the over-time degradation attributed to the read/modify/write issue is typically unknown, so TRIM just helps but doesn't solve the whole enchilada.
Unfortunately, just getting TRIM support implemented in the low levels doesn't solve the entire problem, you also have to teach the filesystems to use it. At this point, even if TRIM was supported, using currently available SSD's on a mail server with tons of small writes means you're doomed to constantly baby sitting the performance of the system since it will 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. Jcr - The OpenBSD Journal. 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 penalty to keep seeking between data and metadata.
'dd' continues to make sense if you need to make a copy of everything before attempting to recover data or metadata. FYI, Mac OS X still benefits from 'dd' because of arguably idiotic Metadata. Trying to get files on an HFS+ volume to remain in tact while copying to/from a non-HFS+ environment is the stuff of nightmares.
Even if you think you have properly retained all that annoying metadata, you'll still have to extract it and test it under whatever application it was which created that metadata. Often, just linefeed conversion (or lack thereof) will break OSX applications. If you want to backup/restore data (for the purposes of imaging and deployment) you really should be using some kind of tar solution. Rsync is nice, but tar works well with everything you'll have in sys and userland.
Tar versions vary, but I disciplined myself from the start to understand the details of OpenBSD tar. I then use a -I /tmp/includes file for specialization. As long as you are creating and extracting your data sources from within OpenBSD (bsd.rd perhaps) tar should do the trick. Using the built-in 'make release' is even more fun.
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 workloads) degrade but never below the performance of even a very fast rotating disk. So, i've stopped worrying about things like TRIM and trying to avoid writes.
I'll align my partitions, but apart from that I just enjoy the extremely low read response times, and my almost-always-quite-low write response times.:) - Jurjen Oskam Savage's Law of Expediency: You want it bad, you'll get it bad. 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 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 course that assumes you only have one disklabel partition, but your servers are probably more complicated than that. 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 course that assumes you only have one disklabel partition, but your servers are probably more complicated than that. The nice thing about dd is that it is simple- you can set up a system with a shell one-liner and after the reboot, just change a few config files. The idea is that novice administrators on our staff could get something up and running quickly. 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 this with CF onto Soekris or other SBCs where actually doing an install directly onto the CF is a PITA (do the install in a VM, then dd the VM's disk). It doesn't need to be simple as long as it saves time and errors.
So I think I will indeed look into ideas like yours. I like Chris Dukes' suggestion to replace baseXX.tgz and use the installer, since unlike Soekris boxes, these machines have CD readers and video hardware. 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 this with CF onto Soekris or other SBCs where actually doing an install directly onto the CF is a PITA (do the install in a VM, then dd the VM's disk). It doesn't need to be simple as long as it saves time and errors.
So I think I will indeed look into ideas like yours. I like Chris Dukes' suggestion to replace baseXX.tgz and use the installer, since unlike Soekris boxes, these machines have CD readers and video hardware. I also keep toying with the idea of an ugly little 'C' program that reads the source page by page. If the page is null, it does a seek instead of a write on the target. As for your soekris deploy method, I wonder if just telling the VM that the block device for the CF is the disk would suffice.
Chris Dukes. 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 course that assumes you only have one disklabel partition, but your servers are probably more complicated than that.
The nice thing about dd is that it is simple- you can set up a system with a shell one-liner and after the reboot, just change a few config files. The idea is that novice administrators on our staff could get something up and running quickly. It's simpler, until your CF vendor decides to change to a slightly smaller device. And then you wish you spent the extra 2 minutes writing a quick shell script to untar things rather than dd, or a site.tgz for the installer. 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 this with CF onto Soekris or other SBCs where actually doing an install directly onto the CF is a PITA (do the install in a VM, then dd the VM's disk). It doesn't need to be simple as long as it saves time and errors.
So I think I will indeed look into ideas like yours. I like Chris Dukes' suggestion to replace baseXX.tgz and use the installer, since unlike Soekris boxes, these machines have CD readers and video hardware. Sounds like you.really.
need to learn pxeboot(8). It's very very straightforward on OpenBSD. 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 workloads) degrade but never below the performance of even a very fast rotating disk.
So, i've stopped worrying about things like TRIM and trying to avoid writes. I'll align my partitions, but apart from that I just enjoy the extremely low read response times, and my almost-always-quite-low write response times.:) I agree. If your application does not require pushing things to their limits, TRIM and degradation can be a non-issue.
When you have the budget to over-allocate with SSD's to exceed your requirements (e.g. A plan to compensate for increased demand as well as degradation over time), then they are an excellent choice. The problems only arise when you don't have the budget, don't understand your workload, don't do adequate testing, and don't plan for the eventual degradation. Since all of these issues except degradation also effect rotating storage, it's mostly a planing problem where SSD's just add other variables to the analysis. The trouble is SSD vendors are not particularly forthcoming about the limitations, so they are not well understood by integrators and this can result in poor planing. Jcr - The OpenBSD Journal.