How to get storage information of the EFI partition? - windows

How can I get the size and current usage of the EFI partition on a disk?
I see that I can use the following command to at least the size of the partition, but I haven't found anything about how to get the current utilization:
get-partition |Where-Object{ $_.GptType -eq "{c12a7328-f81f-11d2-ba4b-00a0c93ec93b}"} |Select Size

As #JeroenMostert mentioned in the comments, this will work well:
Get-Volume -UniqueId "\\?\Volume$(((Get-Partition).Where{$_.GptType -eq '{c12a7328-f81f-11d2-ba4b-00a0c93ec93b}'}.Guid))\" | Select-Object Size, SizeRemaining
The GPT type is the GUID of the EFI partition on Windows, as seen here. This Unique ID is then passed into Get-Volume and will allow one to pull back the size & utilization information.

Related

Using Windows Command Prompt (or PowerShell) to get Disk Drives Listed by Media Type and abbreviated size (GB/TB) as simply as possible

I'm hoping to find a solution that doesn't require a large block of text / code, hopefully only 1 or 2 lines in a .bat script.
So far the main PowerShell call that does these 2 things is the Get-PhysicalDisk, MediaType and Size,
But Size doesn't automatically abbreviate to GB / TB, but I know it or Format Table can, because it does abbreviate to GB / TB if the column it is listed in is restricted in size (width), but I can't figure out a way to force it to?
The standard entry I've used from command prompt is:
PowerShell "Get-PhysicalDisk | FT -AutoSize"
Which gives me something like:
Output on Command-Line
Which looks perfectly fine so long as your HDD / SDDs don't have some insanely long Serial #. In which case you don't even get to see the size. But the real issue is if you want to customize this so you always see the Size ie: PowerShell "Get-PhysicalDisk | FT Size, MediaType, FriendlyName, HealthStatus, OperationalStatus -hideTableHeaders -auto"
Now the size doesn't get summarized in GB, it gets the full number treatment like so:
Output on Command-Line
So is there a way to format or adjust this simply so it'll list in GB, while also having a listed Media Type? (forgot to add that in the end reminder) and if it has to be with a script does anyone have a succinct one?
~TY in advance!
An additional Q, using PowerShell "Get-Disk | FT -auto"
I get a good abbrev in GB as well, but can't |FT the "Total Size" since it has a space in it? or is there a trick to that?
Output on Command-Line
Apply Using PowerShell's Calculated Properties article e.g. as follows:
Get-PhysicalDisk |
Format-Table -Property #{Name='Size GB'; Expression={$_.Size / 1GB}},
MediaType, FriendlyName, HealthStatus, OperationalStatus -AutoSize

What does "mds" use to iterate the mounted file systems?

I have been closely following the Open ZFS development scene for OS X for the last few years. Things have progressed significantly over the last several months since the sad problems that occurred with Greenbytes, etc., but I have been pleased to see that we're finally close to getting real Spotlight support in place. I noticed this email passing by the other day from Jorgen Lundman (who has put a great deal of personal time into getting this going and contributing to the community) and thought perhaps others here might be interested in chiming in on this, his, topic regarding implementing Spotlight support for ZFS on OS X:
To summarize, I think the crux of this question boils down to this:
So then, what does "mds" use to iterate the mounted file systems? I do not
think the sources for "Spotlight-800.28" was ever released so we can't just
go look and learn, like we did for xnu, and IOkit.
It doesn't use the BSD getfsstat(), more likely it asks IOKit, and for some
reason rejects the lower mounts.
And the body of the email for convenience:
Hey guys,
So one of our long-term issues in OpenZFSonOSX is to play nice with Spotlight.
We have reached the point where everything sometimes pretends to work.
For example;
# mdfind helloworld4
/Volumes/hfs1/helloworld4.jpg
/Volumes/hfs2/helloworld4.jpg
/Volumes/zfs1/helloworld4.jpg
/Volumes/zfs2/helloworld4.jpg
Great, picks it up in our regular (control group) HFS mounted filesystems,
as well as the 2 ZFS mounts.
Mounted as:
/dev/disk2 on /Volumes/zfs1 (zfs, local, journaled)
/dev/disk2s1 on /Volumes/zfs2 (zfs, local, journaled)
# diskutil list
/dev/disk1
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *42.9 GB disk1
1: ZFS 42.9 GB disk1s1
2: 6A945A3B-1DD2-11B2-99A6-080020736631 8.4 MB disk1s9
/dev/disk2
#: TYPE NAME SIZE IDENTIFIER
0: zfs_pool_proxy FEST *64.5 MB disk2
1: zfs_filesystem_proxy ssss 64.5 MB disk2s1
So you can see, the actual pool disk is /dev/disk1, and the fake nodes we
create for mounting as /dev/disk2*, as it appears to be required by
Spotlight to work at all. We internally also let the volumes auto-mount,
from issuing "diskutil mount -mountPoint %s %s".
We are not a VOLFS, so there is no ".vol/" directory, nor will mdutil -t
work. But these two points are true for MS-DOS as well, and that does work
with Spotlight.
We correctly reply to zfs.fsbundle's zfs.util for "-p" (volume name) and
"-k" (get uuid), done pre-flight to mounting by DA.
Using FSMegaInfo tool, we can confirm that stat, statfs, readdir, and
similar tests appear to match that of HFS.
So then, the problem.
The problem comes from mounting zfs inside zfs. Ie,
When we mount
/Volumes/hfs1/
/Volumes/hfs1/hfs2/
/Volumes/zfs1/
/Volumes/zfs1/zfs2/
# mdfind helloworld4
/Volumes/hfs1/helloworld4.jpg
/Volumes/hfs1/hfs2/helloworld4.jpg
/Volumes/zfs1/helloworld4.jpg
Absent is of course, "/Volumes/zfs1/zfs2/helloworld4.jpg".
Interestingly, this works
# mdfind -onlyin /Volumes/zfs1/zfs2/ helloworld4
/Volumes/zfs1/zfs2/helloworld4.jpg
And additionally, mounting in reverse:
/Volumes/hfs2/
/Volumes/hfs2/hfs1/
/Volumes/zfs2/
/Volumes/zfs2/zfs1/
# mdfind helloworld4
/Volumes/hfs2/helloworld4.jpg
/Volumes/hfs2/hfs1/helloworld4.jpg
/Volumes/zfs2/helloworld4.jpg
So whichever ZFS filesystem was mounted first, works, but not the second.
So the individual ZFS filesystems are both equal. It is as if it doesn't
realise the lower mount is its own device.
So then, what does "mds" use to iterate the mounted fileystems? I do not
think the sources for "Spotlight-800.28" was ever released so we can't just
go look and learn, like we did for xnu, and IOkit.
It doesn't use the BSD getfsstat(), more likely it asks IOKit, and for some
reason rejects the lower mounts.
Some observations:
# /System/Library/Filesystems/zfs.fs/zfs.util -k disk2
87F06909-B1F6-742F-7355-F0D597849138
# /System/Library/Filesystems/zfs.fs/zfs.util -k disk2s1
8F60C810-2D29-FCD5-2516-2D02EED4566B
# grep uu /Volumes/zfs1/.Spotlight-V100/VolumeConfiguration.plist
<key>uuid.87f06909-b1f6-742f-7355-f0d597849138</key>
# grep uu /Volumes/zfs1/zfs2/.Spotlight-V100/VolumeConfiguration.plist
<key>uuid.8f60c810-2d29-fcd5-2516-2d02eed4566b</key>
Any assistance is appreciated, the main issue tracking Spotlight is;
https://github.com/openzfsonosx/zfs/issues/116
The branch for it;
https://github.com/openzfsonosx/zfs/tree/issue116
vfs_getattr;
https://github.com/openzfsonosx/zfs/blob/issue116/module/zfs/zfs_vfsops.c#L2307
It appears to be down to some undocumented expectations in the vfs_vget method, to lookup entries based entirely on the inode number. Ie, stat /.vol/16777222/1102011
It is expected that vfs_vget sets the vnode_name correctly here, using a call like vnode_update_identity() or similar.

Set Interleave (strip) size of Windows Storage Spaces Mirrored Pool

I'm trying to make a new Windows Storage Space with an interleave of 64kb versus the default of 256kb.
I made a new Mirrored Pool and then tried using the PowerShell Command:
New-VirtualDisk -StoragePoolFriendlyName Pool_T -FriendlyName Disk_T -Interleave 65536 -Size 4GB
How do I verify that this worked correctly?
Get-StoragePool -FriendlyName Pool_T | Get-ResiliencySetting
Gives me the interleave of the pool, how can I get the ones of the storage space?
Get-VirtualDisk -friendlyname Disk_T | fl
The above command gives the Interleave size of the new storage pool and verifies that the Interleave was set as requested during creation.

determine if drive is removable (flash or HDD) knowing only the drive letter

I am trying to determine if a file is on a local drive. I found GetDriveType() WINAPI which retrieves the drive type. However reading the description of the return values it seems, and thats how I understand it, that it retrieves a flash drive as FIXED which is not what I want.
Its working fine on local drives:
bool IsDriveRemovableOrRemote(CString driveRoot)
{
UINT driveType = GetDriveType(driveRoot);
return (DRIVE_REMOVABLE == driveType || DRIVE_CDROM == driveType || DRIVE_NO_ROOT_DIR == driveType || DRIVE_REMOTE == driveType);
}
I don't have a flash/external drive to test ATM but I would like if someone can tell me if my interpretation is correct? and if so, what better alternative should I use?
Please bear in mind that I only have the path of the file.
You should read the doco more closely. While a Flash drive is considered a fixed device, there's a note in that linked page:
To determine whether a drive is a USB-type drive, call SetupDiGetDeviceRegistryProperty and specify the SPDRP_REMOVAL_POLICY property.
The process seems a little messy if all you start with is the path but you can start reading the doco here. It looks like you may need to enumerate the devices until you find one matching your drive.
To avoid doing this to all your requests, I would do a two-stage check. If your current method says it's not fixed, treat it as non-local.
If it says it is fixed, then you can enumerate the devices using my suggested method to be certain.
Alternatively, you can enumerate all fixed non-USB drives the first time you need to, and then just cache the information. I'm pretty certain that the list of these drives won't change while the system is running - drives that get added and deleted are, by definition, removable.
You can try using DeviceIoControl and query for the BusType = BusTypeUsb by passing IOCTL_STORAGE_QUERY_PROPERTY as its second parameter. Read Determining USB by Thomas Lee at the bottom of page.

How can I view the allocation unit size of a NTFS partition in Vista?

Which built in (if any) tool can I use to determine the allocation unit size of a certain NTFS partition ?
Open an administrator command prompt, and do this command:
fsutil fsinfo ntfsinfo [your drive]
The Bytes Per Cluster is the equivalent of the allocation unit.
Use diskpart.exe.
Once you are in diskpart select volume <VolumeNumber> then type filesystems.
It should tell you the file system type and the allocation unit size. It will also tell you the supported sizes etc. Previously mentioned fsutil does work, but answer isn't as clear and I couldn't find a syntax to get the same information for a junction point.
I know this is an old thread, but there's a newer way then having to use fsutil or diskpart.
Run this powershell command.
Get-Volume | Format-List AllocationUnitSize, FileSystemLabel
Another way to find it quickly via the GUI on any windows system:
create a text file, type a word or two (or random text) in it, and save it.
Right-click on the file to show Properties.
"Size on disk" = allocation unit.
The value for BYTES PER CLUSTER - 65536 = 64K
C:\temp>fsutil fsinfo drives
Drives: C:\ D:\ E:\ F:\ G:\ I:\ J:\ N:\ O:\ P:\ S:\
C:\temp>fsutil fsinfo ntfsInfo N:
NTFS Volume Serial Number : 0xfe5a90935a9049f3
NTFS Version : 3.1
LFS Version : 2.0
Number Sectors : 0x00000002e15befff
Total Clusters : 0x000000005c2b7dff
Free Clusters : 0x000000005c2a15f0
Total Reserved : 0x0000000000000000
Bytes Per Sector : 512
Bytes Per Physical Sector : 512
Bytes Per Cluster : 4096
Bytes Per FileRecord Segment : 1024
Clusters Per FileRecord Segment : 0
Mft Valid Data Length : 0x0000000000040000
Mft Start Lcn : 0x00000000000c0000
Mft2 Start Lcn : 0x0000000000000002
Mft Zone Start : 0x00000000000c0000
Mft Zone End : 0x00000000000cc820
Resource Manager Identifier : 560F51B2-CEFA-11E5-80C9-98BE94F91273
C:\temp>fsutil fsinfo ntfsInfo N:
NTFS Volume Serial Number : 0x36acd4b1acd46d3d
NTFS Version : 3.1
LFS Version : 2.0
Number Sectors : 0x00000002e15befff
Total Clusters : 0x0000000005c2b7df
Free Clusters : 0x0000000005c2ac28
Total Reserved : 0x0000000000000000
Bytes Per Sector : 512
Bytes Per Physical Sector : 512
Bytes Per Cluster : 65536
Bytes Per FileRecord Segment : 1024
Clusters Per FileRecord Segment : 0
Mft Valid Data Length : 0x0000000000010000
Mft Start Lcn : 0x000000000000c000
Mft2 Start Lcn : 0x0000000000000001
Mft Zone Start : 0x000000000000c000
Mft Zone End : 0x000000000000cca0
Resource Manager Identifier : 560F51C3-CEFA-11E5-80C9-98BE94F91273
Easiest way, confirmed on 2012r2.
Go to "This PC"
Right click on the Disk
Click on Format
Under drop down "allocation unit size" will be the value of what the Allocation of the Unit size disk already is.
In a CMD (as adminstrator), first run diskpart. In the opened program, enter list disk. It'll list all connected disks.
Select the right disk based on its size. If it is flash memory, usually it'd be the last item in the list. In my case, I select the Disk 2 using this command: select disk 2.
After selecting your disk, list the partitions using list partion command. You'll get a list like the one in the image below.
Now, it is time to select the right partition, based on its size. In my case, I select Partition 1 using this command: select partition 1.
Finally, you can run the filesystem command to get the Allocation Unit Size.
Note: This procedure works on both NTFS and FAT32.
According to Microsoft, the allocation unit size "Specifies the cluster size for the file system" - so it is the value shown for "Bytes Per Cluster" as shown in:
fsutil fsinfo ntfsinfo C:
You can use SysInternals NTFSInfo by Mark Russinovich from the command line and it converts fsutil fsinfo ntfsinfo into more readable information, especially MFT Table info.
The simple GUI way, as provided by J Y in a previous answer:
Create a small file (not empty)
Right-click, choose Properties
Check "Size on disk" (in tab General), double-check that your file size is less than half that so that it is certainly using a single allocation unit.
This works well and reminds you of the significance of allocation unit size. But it does have a caveat: as seen in comments to previous answer, Windows will sometimes show "Size on disk" as 0 for a very small file. In my testing, NTFS filesystems with allocation unit size 4096 bytes required the file to be 800 bytes to consistently avoid this issue. On FAT32 file systems this issue seems nonexistent, even a single byte file will work - just not empty.
from the commandline:
chkdsk l: (wait for the scan to finish)
sizdir32 http://www.ltr-data.se/opencode.html/
start > run > MSINFO32
goto components
goto storage
goto disk
on the right look for Bytes/Sector

Resources