Understanding Core storage, logical volumes, and Fusion drives.

Transcription

1 Understanding Core storage, logical volumes, and Fusion drives. At the root of all of the information for Fusion Drives is Core Storage. From apples support 10.8 Core Technology Over view Core Storage Layered between the whole-disk partition scheme and the file system used for a specific partition is a new logical volume format known as Core Storage, introduced in OS X Lion. Core Storage makes it easy to dynamically allocate partitions while providing full compatibility with existing filesystems. In particular, Core Storage allows in-place transformations such as backgrounding the full-disk encryption used by File Vault 2. We all know how FileVault 2 functions, it dynamically encrypts sections of the disk. It does this by using core storage to manage invisible and seamless breathing partitions keeping both users and overall system sectors separately encrypted. Unlike other encryptions where you allocate an encrypted space, or have everything encrypted Core Storage allows FV2 to move sectors in and out of an encrypted partition. What it means for Logical volumes, and Fusion drives is just an extension of this. A Logical volume is a software based partition that can contain one or more mounted disk in it. In the example above for filevault, Core Storage creates a logical volume for each encrypted section. You can see core storage at work when you encrypt, say a USB thumb drive

2 What s important here is understanding what is happening. Core storage is telling a computer that connects to this, or any other drive that there is information it needs to read before it can mount and use the drive. In this case it s telling the machine it s encrypted. But in other cases, as we will soon see, it can say that these drives are to be read as one drive and need to be addressed in a specific way. What this means for a Fusion Drive is very particular. To understand what a fusion drive is and how it works we must first understand the goal that Apple had in mind when creating a fusion drive. For years people have been using multi drive systems. Boot drive and some files on something fast like an SSD or 10kRPM drive or small drive raid. And all their files or media on something else. The user must manage their data this way and while it provides a nice functionality it s not user friendly to the uninitiated. Fusion drive allows the system to keep track and arrange the files in this system for the user. Lets look at the default configuration for a Mac Mini with Fusion drive; it ships with two drives just like the server version, one is a 128gb SSD and the other a 1tb 2.5 HDD. In the past, the user would choose which drive to install the OS on (the ssd) and the other drive would live permanently mounted on the system. With fusion drives the user sees only one mounted drive, with 1.12tb of space. The system will keep the OS files on the SSD at all times. And in this current iteration of software/firmware will never allow any less than 4gb of free space on the SSD. Files moved to the drive will be dropped onto the SSD until they can be moved off later. IF the files exceed the limit and pressure the SSD to move past that 4gb of space remaining they will be redirected to the slower HDD. As you use the files core storage will manage the data that is on the SSD rearranging less used files to the HDD (demoting) to allow room for the files you are using (promoting). The demotion and promotion of files is based on number of reads. This number can be as little as 2 reads, but presumably many more as the system gets used. Core storage is essentially observing your data usage and learning what you do. This means that the machines using fusion drives can have difficulty when connected (target disk or otherwise) to machines that do not have an understanding of their Logical Volumes. And just like hooking a software managed raid to an external source can cause issues or even break the raid so can issues potentially arise from misuse of a fusion drive system. Thats ok we can repair a raid in Disk Utility, we can of course repair a fusion drive/logical Volume...Right? Unfortunately, when fixing a logical volume in disk utility it will remap the entire setup. Leaving it blank. As stated in the fusion drive training it s extremely important to have a customer backup all data before servicing their fusion drive in anyway. Unlike, say a raid 1 drive, that an repair it self and re mirror a LV does not have the tools to repair it s broken parts. So what does a logical volume look like? Well lets take a look

3 We can see from the above image in Disk Utility there is a mounted volume called LVtest that is a part of what appears to be a single drive. This is actually two drives fused together with Core Storage to create a logical volume of the two of them. It s a total of just under 35gb together and works just like a normal drive. Disk Utility lacks the ability, at the moment to create logical volumes but it can be done through the diskutil command in terminal. We can see that the format of the drive is a Logical partition The Fusion Test disk is actually a Logical Volume Group. This tells us that it s comprised of one or more drives. When we get info on Fusion test we can see more info about the drives Here we can clearly see there are two disks making up this volume. So what do we do in the event there is a core storage failure and we need to recreate a logical volume? Well for now, we need to use terminal.

4 Using core storage via Terminal. The Core storage function of terminal can be evoked by running the diskutil command followed by cs. In it s simplest for the following command will bring up the supported command list. We can see here that there are only a few commands. Here we can do everything from listing the CoreStorage volumes mounted, to breaking them apart and even encrypting them. The tools here also allow us to better support customers with issues revolving around filevault 2 and more. Lets look at invoking a list of volumes

5 Here we can see The base info for the logical volumes. First we see the Volume Group and a volume ID. You ll notice that each sector has a volume ID to help when reconnecting or moving from station to station. These ID hashes can only be read by a machine running an OS with CoreStorage. So anything from 10.7 on. Preferably 10.8 or higher. The volume tells us the overall amount of space, and in this case as I didn t make the volume exact the free unused partition space (874.4mb.) Beneath this we see the two descriptions of the physical volumes, disk1s2 and disk2s2. The drives in a CS LV group will be indexed from 0 onwards. In this case we have two drives so we have disk0 and disk1. What s interesting to note is CS uses volumes and not actual disks so you can create a CS group from a multi-disk volume, say two sets of raid1 drives. Below this is another set of info: Here we see the information for the Volume Family and everything involved in it. It s encryption and the necessary security if it is, and individual partitions in the LV. In this case we have only one called LVtest we see it s formatting etc. It s not encrypted its mounted and it reads in our system as disk3.

6 We can use the diskutil cs info command to get straight down to brass tacks if we already have any key info, like say, the disk, in this case our LVtest volume is mounted as disk3 Most of the same information is present here, but it s very straight forward especially if any of the key information is needed later like UUID s etc. Before we move onto the other parts of CoreStorage lets look at how this is represented in to the system physically via the diskutil info command We can clearly see our boot drive, in this case the 128g SSD that serves as our Macintosh HD. It s partitioned into several parts, We have Our EFI boot, our HFS volume (the HDD it self) and the Recovery partition. Then we can see three other disks. disk1 and disk2 are the two volumes that create the LV. They All too have information stored on them. Unlike a normal drive they have some space taken on them. And here we can understand where the disk1s2 and disk2s2 that we had seen early were coming from. Each LV group has information stored on each drive to represent the group it comes from, including sectors to help a machine understand how to boot or recover if the volume breaks.

7 All this informational stuff is good, and safe to retrieve, the next steps are the dangerous part. It must be reiterated that any command from here on out should only be executed, looked at or run if and only if the customer is backed up. First lets look at how to break a LV. Well look at the delete command first. We can se that the command run on it s own needs more information. The goal of delete is to completely remove any core storage information from any drive associated with a logical volume, the result is two seperate drives. The actual command looks like this:! diskutil cs delete D7B8B5B9-92E0-4F74-BC3A-2B6B9018A3FA That results in the following outputs from terminal

8 This results in two untitled but initialized drives being mounted to the machine. In the case of a fusion drive machine this would be near identical to how machines were setup before fusion drive. As we can see the two mounted drives are back to normal. So how do we glue them back together? Well that s a bit simpler. All we need are the disk identifiers, a name, and a command. First we need to create the LV Group, then we can create an actual volume/disk. First, the Command: We ll use the create command which is pretty simple if we leave it unappended we get the following help info:

9 So once again it is very clear, this will erase everything, on any drive used. Now we need our disk info. Using the get info command in Disk Utility we know our two drives in this case are disk1 and disk2. This will vary based on the machine and the drives, as well as how your booted to the machine, so be sure to always check. According to help we need to format this command right. For this example we ll use the name Core Storage Group. The spaces here are important as they need to be formatted properly in the command. The Command it self will look like this: diskutil cs create "Core Storage Group" disk1 disk2 When we run this command terminal outputs the following What is going on here is each disk is being partitioned, unmounted, erased and held ready to mount while CS figures out what to do with it. Once it s partitions each drive it discovers it and adds it to it s list for the group. Once all disks have been discovered CS begins to make a LV Group of the disks. It then takes the partitions and maps them to CoreStorage. (once again disk1s2 and disk2s2 etc.) The bottom section is a progress bar letting you know it s working away.

10 Here we can see the completed command, After it adds all the disks to the LV Group it and maps them correctly it mounts it which can take a moment. Once it discovers this we get the Volume Group hash represented as the LVG UUID. Disk Utility sees our core storage group but note that we sill don t have any part of it useable. We have our volume group but no actual volume to mount. When working on a fusion drive equipped machine running Disk Utility, this point will allow you to fix the volume after running verify and repair disk and create a new logical volume. This can take some time and will AUTOMATICALLY name it for you. It will literally break and unbreak the group, it just needed the group to begin with. In this process it will completely rename the entire logical volume group, and create and name the volume. The following two images were taken about two minutes apart with out doing anything but pressing Fix.

11 We can se that Core Storage Group was renamed Virtual Whole Disk and there was an automatic volume created called Macintosh HD. None of this was prompted by anything but the fix button. In this way all that is needed to do to repair a customers drive is get to a point where the drives want to be fixed. There are times that Disk Utility will not recognize a problem, and thats why we must break the disks first at times. This could be in the case of the need to reinstall, the Disks aren t recognizing their free space or even if a disk isn t mounting or recognizing properly. Though there is no need to do much more than that, if the need arises you can also create your own logical volumes using the createvolume command. The Command help presents like this.

12 So we can see just how scalable this is There s room here to create a fusion drive with petabytes of information, thats a big internal hard drive! Going back to before we fixed our drive we once again have our Core Storage Group now we need to add a volume. To be exact we ll try and see what happens when we use 100% of volume space and a name of Core Storage Volume using journaled HFS+ Our command will look like this: diskutil cs createvolume F A-997E-8E95C4AC779F jhfs+ "Core Storage Volume" 100% This creates a volume with our name and fills the drive totally with the space. It s possible to fill only parts, it s not recommended to do more than 1 partition with a Fusion Drive (creating two volumes). Core Storage has filled the drive as much as it can with the logical volume, we can see there is a small amount of room take on the drives for overlap. just under.5% of total space. The volume mounts as normal and reads as normal. The result looks like this in Disk Utility.

13 In the end, all we are doing is partitioning or remapping partitions across multiple disks. Disk Utility can only fix a drive into a Macintosh HD and will not allow for any other functionality. That is why we may need or want to use diskutil. The most important take away from this, is any customer using Fusion Drives or core storage should take great heed in backing their information up. Not to imply that fusion drives are unstable, or risky, but rather than they are unrecoverable once failed, with the only result to completely repartition the drives. If a customer needs to seek data recovery they should perform this task before replacing either drive or having us attempt to repair either drive.