Disk order important or not?

[MacUse-R]

I have a SSD as a primary boot drive and a second HDD in the optical drive bay, somehow the primary SSD is showing disk2 while my second HDD shows disk1.

Don´t know why it did it this way? Anyway, does the order of the disk matter, does it make any difference at all that my primary drive is showing disk 2?

If that matters then is there any way of changing the order without formatting?
And if formatting needs to be done how do i manually specify which disk number a disk shall get?

Macbook pro 2011 with High Sierra, APFS on the primary SSD drive (disk2) and ExFAT on the second drive (disk1).

 

[BLUEDOG314]

Can't think of any reason this would be important. Im not completely sure on this part but a lot of times the optical bay is SATA II speed, but for a mechanical drive that shouldn't matter anyway. Even so, that is how the computer is assigning device identifiers which is usually first come first serve, so I would think if you maybe nuked both drives, then removed the HDD and like rebooted, cleared NVRAM, and reinstalled the OS on the SSD then put the other drive in, it would probably work.

 

[DeltaMac]

The system-assigned disk number sequence has very little importance to the user. There are some configurations and other drive procedures that need the disk sequence numbers for some kind of manual drive manipulation, but that is not needed in any ordinary use.
The important setting is making sure that your default boot drive is set properly in the Startup Disk pref pane. You may even notice that the disk numbers are not relevant in that pane, where there are only partition names. I'm sure that at a low level, the disk numbers are used, but the macOS system takes care of all that for you. It's a very rare need when you would actually use the disk number assignments.

 

[MacUse-R]

Thanks for your answers.
Well as long as the primary drive doesnt need to be first in the order and it doesnt make any problems then im happy regardless in which order the disks are arranged.

The strange thing is that i reinstalled the operating system on the new SSD and installed it in the primary hard drive bay and after that i installed the newly formatted mechanical hard drive as a second drive in the optical drive bay, yet the primary SSD was assigned second in the order.

 

[BrianBaughn]

I’m not even sure the disk numbers are static between reboots.

 

[MacUse-R]

I’m not even sure the disk numbers are static between reboots.

Well so far they have had the same number after every reboot.

I guess the first SSD was assigned as disk2 and then later when i installed the second HDD it was assigned disk1 since it was availible, but in that case it still sounds a bit strange why the SSD was assigned disk2?

Anyway i dont care as long as it doesnt cause any problems?

 

[BrianBaughn]

I'm pretty sure the only time a user should be concerned with what disk is what number is when performing actions, such as in Terminal, that are disk specific.

 

[organicCPU]

It could matter for Target Disk Mode. With multiple drives installed, Target Disk Mode just mounts the first drive attached at the disk drive interface. Though, I don't say that the device identifier is referring to that order.

 

[MacUse-R]

I'm pretty sure the only time a user should be concerned with what disk is what number is when performing actions, such as in Terminal, that are disk specific.

Well i guess in such cases its okay anyway as long as i keep track of which drive has what didk number? So i guess it doesnt hinder me from doing things in Terminal?
[doublepost=1521704005][/doublepost]

It could matter for Target Disk Mode. With multiple drives installed, Target Disk Mode just mounts the first drive attached at the disk drive interface. Though, I don't say that the device identifier is referring to that order.

Interesting, but one would think that there is some way of telling Target disk mode which drive it shall mount, at least through a Terminal command?

I wonder if there is some way of changing the disk number for a certain hard drive?

 

[BrianBaughn]

Well i guess in such cases its okay anyway as long as i keep track of which drive has what didk number? So i guess it doesnt hinder me from doing things in Terminal?
[doublepost=1521704005][/doublepost]

Interesting, but one would think that there is some way of telling Target disk mode which drive it shall mount, at least through a Terminal command?

I wonder if there is some way of changing the disk number for a certain hard drive?

When performing Terminal tasks on disks it's wise to check those disk numbers.

If you search the web I think you'll find info about mounting disks via Terminal and Target Disk Mode.

 

[organicCPU]

Interesting, but one would think that there is some way of telling Target disk mode which drive it shall mount, at least through a Terminal command?

It's been a while ago that I've been using Target Disk Mode on a Mac with multiple internal drives, but there was definitely no way accessing any other drive than the first physical one (the master ATA). Accessing another drive remotely was only possible through networking, that is different to TDM. I can't find any official source for my statement and there are users reporting that they could access all drives including optical ones through Target Disk Mode, but for me that has never been working.

 

[MacUse-R]

Hmm, i have now looked at the list disk command with Terminal, instead of only with disk utility like earlier.

Now that got me confused, if you look at the screenshot you can see 3 disks, disk0, disk1 and disk2
(and disk3 which is an external hard drive, so just forget about that one).

Disk0 seems to be the primary SSD drive since it is around 500 GB and has the filesystem APFS, and then the disk1 is the 2TB secondary drive, and finally disk2 is ALSO the same 500GB primary SSD drive.

By the way, disk2 (SSD) also has the word "synthesized", don't know what that means?

So how can the SSD have two different disk numbers? And in that case will the Mac see the primary SSD as disk0 or disk2 ?

Some help would be appreciated, this got me a bit confused. If I remember it correctly I have never seen another disk this way in list disk. Is it maybe because its an SSD with APFS filesystem? But shouldn't the SSD in that case have the two disk numbers in a row, for example disk0 and disk1?

EDIT: It seems the whole primary SSD drive is disk0, but the partition on that same drive is disk2 ?
Does everything look normal in the attached screenshoot of my disks?

[doublepost=1522047109][/doublepost]By the way, another question. I have reformatted the 2TB hard drive so it can work with Time Machine, but I noticed that it has 852 MB used space on it. Paragon Hard disk manager says that some of that is an EFI partition and some of it is "free".
So my question is....can I delete the EFI partition since this is a secondary internal hard drive, i.e. it has no operating system on it, just using it as a storage drive. My primary SSD is the one with Mac OS on it and it of course also has EFI partitions etc.

 

[dsemf]

What you see is normal.

When you upgraded, the original HFS partition on disk0 was changed to an APFS Container. The container is mapped to disk2 with an additional volume, Preboot, required to boot using APFS. The Recovery volume was also moved into the container. disk0 is the physical disk, disk2 is a logical or virtual disk representing the contents of the container.

DS

 

[organicCPU]

In addition to what @dsemf wrote you can get a more in-depth overview of the APFS containers by:

diskutil apfs list

So my question is....can I delete the EFI partition since this is a secondary internal hard drive, i.e. it has no operating system on it, just using it as a storage drive.

Formatting a drive in Disk Utility HFS+ (journaled) with GUID partition table creates an EFI partition. As the EFI partition only takes 209.7 MB of your disk space, I'd recommend just to leave it in place and not to delete it.

This EFI partition could get handy, especially if you're ever going to install a newer macOS on one internal drive while keeping an older macOS on the second internal drive.

However, you're right, that you won't need the EFI partition, if never installing an OS on that drive. So you probably could delete it. Beware of this could potentially delete data that you don't want to delete. You should have backups ready, ideally of all attached drives.

 

[MacUse-R]

What you see is normal.

When you upgraded, the original HFS partition on disk0 was changed to an APFS Container. The container is mapped to disk2 with an additional volume, Preboot, required to boot using APFS. The Recovery volume was also moved into the container. disk0 is the physical disk, disk2 is a logical or virtual disk representing the contents of the container.

DS

Okay i see, interesting. Then this seems to be a way specific to APFS, since i cant remember seeing that type of setup with other filesystems, or maybe im wrong?

I also have a partition called VM, which i now know what it is, but i dont like it writing to my SSD. The VM partition is more than 13 GB in size.
[doublepost=1522135055][/doublepost]

In addition to what @dsemf wrote you can get a more in-depth overview of the APFS containers by:

diskutil apfs list

Formatting a drive in Disk Utility HFS+ (journaled) with GUID partition table creates an EFI partition. As the EFI partition only takes 209.7 MB of your disk space, I'd recommend just to leave it in place and not to delete it.

This EFI partition could get handy, especially if you're ever going to install a newer macOS on one internal drive while keeping an older macOS on the second internal drive.

However, you're right, that you won't need the EFI partition, if never installing an OS on that drive. So you probably could delete it. Beware of this could potentially delete data that you don't want to delete. You should have backups ready, ideally of all attached drives.

You are right, its so small partition that i can leave it like it is, i never thought it can have any use on the secondary internal hard drive, but you just gave me a reason to keep it.

I also have two more partitions that are also around 260 MB or something like that and in Paragon Hard drive manager they are called "free", so it seems its free space, i dont know why they were created in the first place?
The strange thing is that the MacBook Pro doesnt show them even with the Terminal command, so maybe they dont exist, maybe Paragon is showing something that is not existing or ive misread it somehow?

That free space i guess i can merge with my big partition that i use, without loosing any of the data on the big partition?

By the way, does anybody know if the debug meny can be enabled in disk utility in High Sierra? I could not get it enabled the usual way when i tried it in High Sierra?

 

[organicCPU]

I also have a partition called VM, which i now know what it is, but i dont like it writing to my SSD. The VM partition is more than 13 GB in size.

Modifying the VM partition or how your Mac is handling virtual memory such as sleepimages and swapfiles in general is a bad idea.

Swapfiles are needed for transferring certain parts of RAM content to files on disk (virtual memory). If you modify this, you risk that your memory management breaks and your Mac crashes.

Concerning sleepimages, the whole content of RAM is written to a file on disk, each time your Mac goes to sleep. You could prevent writing a sleepimage by modifying hibernatemode in power management settings (see 'man pmset'), but this could lead to unexpected behaviour or malfunction of your sleep functions.

Better don't mess with those settings or the VM partition, as long as your Mac is working like expected.

I also have two more partitions that are also around 260 MB or something like that and in Paragon Hard drive manager they are called "free", so it seems its free space, i dont know why they were created in the first place?
The strange thing is that the MacBook Pro doesnt show them even with the Terminal command, so maybe they dont exist, maybe Paragon is showing something that is not existing or ive mistead it somehow?
That free space i guess i can merge with my big partition that i use, without loosing any of the data on the big partition?

I've never been using Paragon Hard drive manager, so I can't tell you if that's more trustworthy than the Terminal diskutil command.

Merging partitions without loosing data can work under certain conditions. E.g. the first partition has to be a resizable filesystem like JHFS+, the order of partitions that you merge needs to be in sequence and all partitions except the first one needs to be unmountable. See 'man diskutil' -> mergePartitions for more details.

However, having at least a backup of important data or preferable a bootable backup is ALWAYS advised, especially if playing around with less known disk operation commands or performing other system maintenance tasks like OS updates, etc.

By the way, does anybody know if the debug meny can be enabled in disk utility in High Sierra?

There is no more debug menu in Disk Utility since Mac OS X El Capitan. All you can do is to use either the Terminal or third party tools for certain functions.

 

[MacUse-R]

Modifying the VM partition or how your Mac is handling virtual memory such as sleepimages and swapfiles in general is a bad idea.

Swapfiles are needed for transferring certain parts of RAM content to files on disk (virtual memory). If you modify this, you risk that your memory management breaks and your Mac crashes.

Concerning sleepimages, the whole content of RAM is written to a file on disk, each time your Mac goes to sleep. You could prevent writing a sleepimage by modifying hibernatemode in power management settings (see 'man pmset'), but this could lead to unexpected behaviour or malfunction of your sleep functions.

Better don't mess with those settings or the VM partition, as long as your Mac is working like expected.


I've never been using Paragon Hard drive manager, so I can't tell you if that's more trustworthy than the Terminal diskutil command.

Merging partitions without loosing data can work under certain conditions. E.g. the first partition has to be a resizable filesystem like JHFS+, the order of partitions that you merge needs to be in sequence and all partitions except the first one needs to be unmountable. See 'man diskutil' -> mergePartitions for more details.

However, having at least a backup of important data or preferable a bootable backup is ALWAYS advised, especially if playing around with less known disk operation commands or performing other system maintenance tasks like OS updates, etc.


There is no more debug menu in Disk Utility since Mac OS X El Capitan. All you can do is to use either the Terminal or third party tools for certain functions.

Thanks for the info.
The Swapfiles i am not going to mess with, but i have set hibernation to 0 in order to stop sleeepimage writes, but that by itself wasnt enough in High Sierra. The sleepimge reappered all the time, i needed to delete the sleepimage file and then create a new empty sleepimage file and lock it so that the mac couldnt write anything to the sleepimage file.
Dont know if this procedure is new to High Sierra?

 

[organicCPU]

Dont know if this procedure is new to High Sierra?

From the macOS Sierra man page:

To disable hibernation images completely, ensure hibernatemode standby and autopoweroff are all set to 0

I've also set hibernatemode to 0 on a MBP running Mac OS X 10.8 without any file locking tricks. In my experience setting hibernatemode to 0 doesn't prevent writing a sleepimage as large as the RAM, but it can prevent writing to that file on every sleep. It seems that the sleepimage is still written or modified, if you turn off the Mac. For me it's o.k. to save at least some disk writes and let the Mac write a sleepimage occasionally (last time it happened before Christmas...). If there were changes in HS I don't know.

 

[MacUse-R]

From the macOS Sierra man page:

I've also set hibernatemode to 0 on a MBP running Mac OS X 10.8 without any file locking tricks. In my experience setting hibernatemode to 0 doesn't prevent writing a sleepimage as large as the RAM, but it can prevent writing to that file on every sleep. It seems that the sleepimage is still written or modified, if you turn off the Mac. For me it's o.k. to save at least some disk writes and let the Mac write a sleepimage occasionally (last time it happened before Christmas...). If there were changes in HS I don't know.

Okay so you havent touched the autostandby and the autopoweroff parameters?

I occasionally power off my current MacBook Pro, but not as many times as DriveX says about the power cycle count of my new SSD (over 100 times in 1 month since i purchesed the SSD), i guess the real number is maybe around 30. Maybe it counts sleep cycles as well?
My old MBP i newer powered off.
Ive read somewhere that Mac's are made to not be powered off for long times.
I don't know if powering OFF and ON the Mac is a bad thing for any of the components?

 

[organicCPU]

Okay so you havent touched the autostandby and the autopoweroff parameters?

For battery and AC power my settings are standby 0, autopoweroff 1. As far as I remember I've never been changing that. That autopoweroff is on doesn't matter for me as there are always external drives connected for backup, means Safe Sleep will never get entered.

I occasionally power off my current MacBook Pro, but not as many times as DriveX says about the power cycle count of my new SSD (over 100 times in 1 month since i purchesed the SSD), i guess the real number is maybe around 30. Maybe it counts sleep cycles as well?

Do you refer to DriveDx? According to Apple putting hard disks to sleep doesn't affect SSDs. I don't know under which circumstances exactly a SSD is getting powered off (Sleep, Standby or just Safe Sleep, maybe influenced from Power Nap, too). Nonetheless, I didn't find any reference that the number of power cycles will affect a SSD's health. As there is no parking position like that of a mechanical HDD head, it shouldn't have deep impact on the SSD lifespan, provided it's a regular power off and on.

I don't know if powering OFF and ON the Mac is a bad thing for any of the components?

It's hard to tell, because you never know what had happened, if you did the opposite. In fact a Mac can be powered on for a long time without breaking. I'd ask the question like this: does it make sense for your use case to have it powered on 24 hours, 7 days a week? If your answer is yes, then it might be no problem at all to have it just running. The less people use their Mac, the more they tend to switch it off. No problem, either.
My oldest Macs in service are around 22 years old. I've been using them for several years 24/7. Now they get used on occasion, e.g. as a softrouter serving a 128 KBit dial-up modem card, but most of the time they're switched off. No problems aside of a more often empty PRAM battery, that I had to exchangeseveral times. My oldest laptop, a PowerBook G4 that is still working, went out of service after 11 years of almost running 24/7. Its battery is broken and there is a sleep issue that makes it crash. If I ever find the time, I'm going to repair it. However, it did a good job to me for years.

 

[MacUse-R]

For battery and AC power my settings are standby 0, autopoweroff 1. As far as I remember I've never been changing that. That autopoweroff is on doesn't matter for me as there are always external drives connected for backup, means Safe Sleep will never get entered.

Do you refer to DriveDx? According to Apple putting hard disks to sleep doesn't affect SSDs. I don't know under which circumstances exactly a SSD is getting powered off (Sleep, Standby or just Safe Sleep, maybe influenced from Power Nap, too). Nonetheless, I didn't find any reference that the number of power cycles will affect a SSD's health. As there is no parking position like that of a mechanical HDD head, it shouldn't have deep impact on the SSD lifespan, provided it's a regular power off and on.

It's hard to tell, because you never know what had happened, if you did the opposite. In fact a Mac can be powered on for a long time without breaking. I'd ask the question like this: does it make sense for your use case to have it powered on 24 hours, 7 days a week? If your answer is yes, then it might be no problem at all to have it just running. The less people use their Mac, the more they tend to switch it off. No problem, either.
My oldest Macs in service are around 22 years old. I've been using them for several years 24/7. Now they get used on occasion, e.g. as a softrouter serving a 128 KBit dial-up modem card, but most of the time they're switched off. No problems aside of a more often empty PRAM battery, that I had to exchangeseveral times. My oldest laptop, a PowerBook G4 that is still working, went out of service after 11 years of almost running 24/7. Its battery is broken and there is a sleep issue that makes it crash. If I ever find the time, I'm going to repair it. However, it did a good job to me for years.

Yes i mean DriveDx, its the software that shows different health parameters of your drives etc.
Actually i noticed yesterday that the power cycle count was actually a whopping 171 in about 1 month time, i have definetely not powered the MBP/SSD ON and OFF that many times, not even near.
Well i use it in the morning and then i dont use it for the whole day until i come home from work, my MBP has a second HDD but i dont care about the HDD as much as the SSD, so the HDD would not be a reason to turn off the MBP.

 

[organicCPU]

Actually i noticed yesterday that the power cycle count was actually a whopping 171 in about 1 month time, i have definetely not powered the MBP/SSD ON and OFF that many times, not even near.

Although I really think that the power cycle count doesn't matter, there could be some hints why the SSD powers off inside the log of pmset (better write it to a file, because the output is quite long):

pmset -g everything > ~/Desktop/pmsetlog.txt

 

[MacUse-R]

Although I really think that the power cycle count doesn't matter, there could be some hints why the SSD powers off inside the log of pmset (better write it to a file, because the output is quite long):

pmset -g everything > ~/Desktop/pmsetlog.txt

Thanks, im going to check that out as soon as Im back on the MBP.
Im a bit curious why it shows that kind of high power cycle count in DriveDX.