@scottalanmiller said in Purchasing new hard drives: Embrace 4kn?:
@EddieJennings said in Purchasing new hard drives: Embrace 4kn?:
I know my RAID controller supports it and Windows Server 2012 R2 supports it.
Windows shouldn't be installed directly on the RAID controller, you should have a hypervisor layer in between that will talk to the storage directly. Windows should only be seeing the VHD and not care what is underneath.
I know. The environment I'm in should be virtualized.
From: https://msdn.microsoft.com/windows/compatibility/advanced-format-disk-compatibility-update
This topic introduces the effect of Advanced Format storage devices on software, discusses what apps can do to help support this type of media, and discusses the infrastructure that Microsoft introduced with Windows Vista, Windows 7, and Windows 8 to enable developers to support these types of devices.<
I must've misunderstand the usage of apps. Article was a good read.
We're moving from using a Synology 1512 with consumer drives to local storage (am eyeing Seagate Enterprise hard drives) for one of our servers. I'm presented with whether or not I want to use hard drives with native 4K sectors.
I know my RAID controller supports it and Windows Server 2012 R2 supports it. I also know the existing drives (Intel s3500) are 512e, as fsutil fsinfo ntfsinfo shows the sector size as 512 bytes and the physical sector size as 4096 bytes. Also, the iSCSI drive that the Synology presents also shows the same sector sizes.
Assuming my company's web application supports this 4k environment, would there be any reason to avoid the new 4kn drives?
Also always, thanks my fellow Mangolassi folk for aiding in my learning 
Just ordered a refurbished Dell R310 from Stallard Technologies.
@scottalanmiller Yeah. I was surprised. Actually only the last 3 years have been in the 40% range.
Total storage consumed:
2009: 9 GB
2010: 20 GB
2011: 40 GB
2012: 68 GB
2013: 116 GB
2014: 172 GB
2015: 253 GB
2016: 369 GB
That's not huge about of storage consumed by any means, but it was curious to see what the percentage of growth has been. Useful information for trying to get an idea of future storage needs.
@NerdyDad Did my math incorrect before. Average growth of the total storage used on the NAS is 44% / year.
@NerdyDad The largest of folders has grown about 150% each year for the last several, which has prompted me to look at more data.
Determining storage usage since the beginning of time for our NAS (2010) to get an idea of possible storage requirements in the future.
Waiting for oil change, tire rotation, and alignment at Toyota.
@BRRABill Once you make the MX record change, make sure you keep MDaemon up for a bit until you're sure the MX change has propagated and MDaemon is no longer receiving traffic.
We migrated from MDaemon to Exchange Online a couple of years ago. It was a pretty smooth process -- especially using the IMAP migration for preserving mailbox contents.
@EddieJennings And growth? 500 GB in about 6 years (which I believe is the age of the NAS and its drives).
@Texkonc Yeah, I know I can't have 5 in a RAID 10. Currently we're using under 500 GB of this storage, so losing that drive isn't significant. Once my current two hair-on-fire esque tasks are done, I'll get on figuring out the procedure.
Wealth of knowledge has been gained in the last few minutes -- in particular how long it would take to resilver an array, which puts into perspective how dangerous RAID 5 is.
@scottalanmiller The chance of failure on the resilver is what frightens me, which, contrary to what I posted a couple of minutes ago, makes me want to make the drive swap happen when I redo the RAID as RAID 10. For that matter, I'll also look and see what the cost would be to add drives to the server that connects to the NAS via iSCSI and just have the data stored locally.
@Texkonc I have one in stock already, and I agree with you and @DustinB3403 it would be wiser to go ahead and take care of this now. Especially since I don't have a solid idea of when I can get to the project of getting off the RAID 5.
