getVolInfo question

getVolInfo question

[Lavrentiev, Anton (NIH/NLM/NCBI) [C]]

Hi Corinna,

I have a question about this tool getVolInfo that has recently "made the news".

Just updated my version to the latest and tried it on my drive C:, and specifically this is what bugs me:

$ /usr/lib/csih/getVolInfo.exe .
...
SectorInfoFlags    : 0x03
  SSINFO_FLAGS_NO_SEEK_PENALTY      : FALSE
  SSINFO_FLAGS_TRIM_ENABLED         : FALSE

I presume the values shown are described here:
https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-fscc/3e75d97f-1d0b-4e47-b435-73c513837a57

But my drive (well, all NTFS) does have TRIM enabled:

$ fsutil behavior query disabledeletenotify
DisableDeleteNotify = 0

Which is also confirmed by other tools... (like SSD "dashboards" etc.)

Thanks,

Anton Lavrentiev
Contractor NIH/NLM/NCBI

Re: getVolInfo question

[Corinna Vinschen]

On Dec  7 15:35, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via Cygwin wrote:
> Hi Corinna,
> 
> I have a question about this tool getVolInfo that has recently "made the news".
> 
> Just updated my version to the latest and tried it on my drive C:, and specifically this is what bugs me:
> 
> $ /usr/lib/csih/getVolInfo.exe .
> ...
> SectorInfoFlags    : 0x03
>   SSINFO_FLAGS_NO_SEEK_PENALTY      : FALSE
>   SSINFO_FLAGS_TRIM_ENABLED         : FALSE
> 
> I presume the values shown are described here:
> https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-fscc/3e75d97f-1d0b-4e47-b435-73c513837a57
> 
> But my drive (well, all NTFS) does have TRIM enabled:
> 
> $ fsutil behavior query disabledeletenotify
> DisableDeleteNotify = 0
> 
> Which is also confirmed by other tools... (like SSD "dashboards" etc.)

Yes, but!

fsutil behavior query disabledeletenotify *only* shows if the OS
supports disabledeletenotify, i.e., TRIM, on a system-wide base(*).
It does *not* tell you if TRIM is really enabled on an existing
filesystem on any of your drives.

TRIM is only enabled on a filesystem, if the underlying drive
actually supports TRIM.  The majority of SSDs support it, but not
necessarily all SSDs.

The above values, in particular SSINFO_FLAGS_NO_SEEK_PENALTY being
FALSE, indicate that your drive is actually not an SSD, but a rotating
harddisk, or it's an SSD which fakes to be a rotating harddisk.

I have a laptop with a Samsung 830 SSD, and getVolInfo prints:

  SectorInfoFlags    : 0x0f
    SSINFO_FLAGS_NO_SEEK_PENALTY      : TRUE
    SSINFO_FLAGS_TRIM_ENABLED         : TRUE

I'm running a with NTFS and ReFS on virtual filebacked drives,
the ReFS actually spanning two virtual drives.

csih prints

  SectorInfoFlags    : 0x0b
    SSINFO_FLAGS_NO_SEEK_PENALTY      : FALSE
    SSINFO_FLAGS_TRIM_ENABLED         : TRUE

for the NTFS FS, and

  SectorInfoFlags    : 0x03
    SSINFO_FLAGS_NO_SEEK_PENALTY      : FALSE
    SSINFO_FLAGS_TRIM_ENABLED         : FALSE

for the ReFS FS.


Corinna

(*) FWIW, on Windows 11, this is even split into two values for NTFS
    and ReFS separately.

Re: getVolInfo question

[Corinna Vinschen]

On Dec  7 18:04, Corinna Vinschen via Cygwin wrote:
> On Dec  7 15:35, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via Cygwin wrote:
> > Hi Corinna,
> > 
> > I have a question about this tool getVolInfo that has recently "made the news".
> > 
> > Just updated my version to the latest and tried it on my drive C:, and specifically this is what bugs me:
> > 
> > $ /usr/lib/csih/getVolInfo.exe .
> > ...
> > SectorInfoFlags    : 0x03
> >   SSINFO_FLAGS_NO_SEEK_PENALTY      : FALSE
> >   SSINFO_FLAGS_TRIM_ENABLED         : FALSE
> > 
> > I presume the values shown are described here:
> > https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-fscc/3e75d97f-1d0b-4e47-b435-73c513837a57
> > 
> > But my drive (well, all NTFS) does have TRIM enabled:
> > 
> > $ fsutil behavior query disabledeletenotify
> > DisableDeleteNotify = 0
> > 
> > Which is also confirmed by other tools... (like SSD "dashboards" etc.)
> 
> Yes, but!
> 
> fsutil behavior query disabledeletenotify *only* shows if the OS
> supports disabledeletenotify, i.e., TRIM, on a system-wide base(*).
> It does *not* tell you if TRIM is really enabled on an existing
> filesystem on any of your drives.
> 
> TRIM is only enabled on a filesystem, if the underlying drive
> actually supports TRIM.  The majority of SSDs support it, but not
> necessarily all SSDs.
> 
> The above values, in particular SSINFO_FLAGS_NO_SEEK_PENALTY being
> FALSE, indicate that your drive is actually not an SSD, but a rotating
> harddisk, or it's an SSD which fakes to be a rotating harddisk.
> 
> I have a laptop with a Samsung 830 SSD, and getVolInfo prints:
> 
>   SectorInfoFlags    : 0x0f
>     SSINFO_FLAGS_NO_SEEK_PENALTY      : TRUE
>     SSINFO_FLAGS_TRIM_ENABLED         : TRUE
> 
> I'm running a with NTFS and ReFS on virtual filebacked drives,
             ^^^
          a Qemu/KVM VM

> the ReFS actually spanning two virtual drives.
> 
> csih prints
> 
>   SectorInfoFlags    : 0x0b
>     SSINFO_FLAGS_NO_SEEK_PENALTY      : FALSE
>     SSINFO_FLAGS_TRIM_ENABLED         : TRUE
> 
> for the NTFS FS, and
> 
>   SectorInfoFlags    : 0x03
>     SSINFO_FLAGS_NO_SEEK_PENALTY      : FALSE
>     SSINFO_FLAGS_TRIM_ENABLED         : FALSE
> 
> for the ReFS FS.

Needless to say that on both systems, fsutil prints:

Windows-10$ fsutil behavior query disabledeletenotify
NTFS DisableDeleteNotify = 0  (Disabled)
ReFS DisableDeleteNotify = 0  (Disabled)

Windows-11$ fsutil behavior query disabledeletenotify
NTFS DisableDeleteNotify = 0  (Allows TRIM operations to be sent to the storage device)
ReFS DisableDeleteNotify = 0  (Allows TRIM operations to be sent to the storage device)

> (*) FWIW, on Windows 11, this is even split into two values for NTFS
>     and ReFS separately.

...and on W10 as well.

RE: [EXTERNAL] Re: getVolInfo question

[Lavrentiev, Anton (NIH/NLM/NCBI) [C]]

Thank you for your prompt reply!

> TRIM is only enabled on a filesystem, if the underlying drive
> actually supports TRIM.  The majority of SSDs support it, but not
> necessarily all SSDs.
> 
> The above values, in particular SSINFO_FLAGS_NO_SEEK_PENALTY being
> FALSE, indicate that your drive is actually not an SSD, but a rotating
> harddisk, or it's an SSD which fakes to be a rotating harddisk.

Well, I don't have any rotating HHDs in my computer.  4 of my SSDs report this:

TRIM Command:  Supported (Deterministic Read After TRIM, Words = 0)

and the last one (an older drive, indeed) report this:

TRIM Command:  Supported (Indeterminate Read After TRIM)

But my C: drive (where Cygwin is installed) is a newer drive (one of those 4).

That's odd.

Also, the fact that I am unable to restore any files after deletion (all contents become
0), just experimenally supports the fact that the drives do trim the deleted sectors.

(And no, I do not have any secure deletion or anything like that enabled; when this PC had
HDDs in the past, the files were perfectly recoverable.)

Anton Lavrentiev
Contractor NIH/NLM/NCBI

Re: [EXTERNAL] Re: getVolInfo question

[Corinna Vinschen]

On Dec  7 18:02, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via Cygwin wrote:
> Thank you for your prompt reply!
> 
> > TRIM is only enabled on a filesystem, if the underlying drive
> > actually supports TRIM.  The majority of SSDs support it, but not
> > necessarily all SSDs.
> > 
> > The above values, in particular SSINFO_FLAGS_NO_SEEK_PENALTY being
> > FALSE, indicate that your drive is actually not an SSD, but a rotating
> > harddisk, or it's an SSD which fakes to be a rotating harddisk.
> 
> Well, I don't have any rotating HHDs in my computer.  4 of my SSDs report this:
> 
> TRIM Command:  Supported (Deterministic Read After TRIM, Words = 0)
> 
> and the last one (an older drive, indeed) report this:
> 
> TRIM Command:  Supported (Indeterminate Read After TRIM)
> 
> But my C: drive (where Cygwin is installed) is a newer drive (one of those 4).
> 
> That's odd.

Yes, it is.  But getVolInfo can only print what it gets from the OS,
so I don't see what could be changed ¯\_(ツ)_/¯

I was mulling over the idea that accessing the drive from remote might
be the culprit, but I just tested accessing the SSD in my laptop from
my Windows 11 VM, and it turns out that it works just as if the drive
is local:

  $ /usr/lib/csih/getVolInfo.exe //pinky/c\$/cygwin64
  Device Type        : 0x07
  Characteristics    : 0x00000010
    FILE_REMOVABLE_MEDIA              : FALSE
    FILE_REMOTE_DEVICE                : TRUE
  Volume Name        : <>
  Serial Number      : 1056954926
  Max Filenamelength : 255
  Filesystemname     : <NTFS>
  Flags              : 0x00c706ff
    FILE_CASE_SENSITIVE_SEARCH        : TRUE
    [...]
    FILE_SUPPORTS_GHOSTING            : FALSE
  SectorInfoFlags    : 0x0f
    SSINFO_FLAGS_NO_SEEK_PENALTY      : TRUE
    SSINFO_FLAGS_TRIM_ENABLED         : TRUE

Having said that, if you or anybody else find out why this happens
and, ideally, how to workaround it, I'm all ears.


Corinna

Re: [EXTERNAL] Re: getVolInfo question

[Corinna Vinschen]

On Dec  7 19:53, Corinna Vinschen via Cygwin wrote:
> On Dec  7 18:02, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via Cygwin wrote:
> > Thank you for your prompt reply!
> > 
> > > TRIM is only enabled on a filesystem, if the underlying drive
> > > actually supports TRIM.  The majority of SSDs support it, but not
> > > necessarily all SSDs.
> > > 
> > > The above values, in particular SSINFO_FLAGS_NO_SEEK_PENALTY being
> > > FALSE, indicate that your drive is actually not an SSD, but a rotating
> > > harddisk, or it's an SSD which fakes to be a rotating harddisk.
> > 
> > Well, I don't have any rotating HHDs in my computer.  4 of my SSDs report this:
> > 
> > TRIM Command:  Supported (Deterministic Read After TRIM, Words = 0)
> > 
> > and the last one (an older drive, indeed) report this:
> > 
> > TRIM Command:  Supported (Indeterminate Read After TRIM)
> > 
> > But my C: drive (where Cygwin is installed) is a newer drive (one of those 4).
> > 
> > That's odd.
> 
> Yes, it is.  But getVolInfo can only print what it gets from the OS,
> so I don't see what could be changed ¯\_(ツ)_/¯

Btw., I took the opportunity trying to implement the Linux FITRIM ioctl.

FTR, it works, kind of.

The problem is this:

- In Linux, ioctl(FITRIM) only works on filesystem descriptors (e.g.,
  /dev/sda1).  When trying to call ioctl(FITRIM) on file descriptors
  (e.g. /tmp/foo), the ioctl returns -1 with errno set to EOPNOTSUPP.

- In Windows, DeviceIoControl(FSCTL_FILE_LEVEL_TRIM) works on files
  handles.  It fails with ERROR_INVALID_ARGUMENT when called on
  filesystem handles.

So the usage patterns are mutually exclusive.

Additionally I found that DeviceIoControl(FSCTL_FILE_LEVEL_TRIM) can
fail with ERROR_FILE_LEVEL_TRIM_NOT_SUPPORTED even if
SSINFO_FLAGS_TRIM_ENABLED is TRUE, in my case with NTFS on the
file-backed virtual drive used from a Win11 VM.

This is soooo frustrating :(((


Corinna

Re: getVolInfo question

[ASSI]

Lavrentiev, Anton (NIH/NLM/NCBI) [C] via Cygwin writes:
> Just updated my version to the latest and tried it on my drive C:, and specifically this is what bugs me:
>
> $ /usr/lib/csih/getVolInfo.exe .
> ...
> SectorInfoFlags    : 0x03
>   SSINFO_FLAGS_NO_SEEK_PENALTY      : FALSE
>   SSINFO_FLAGS_TRIM_ENABLED         : FALSE
>
> I presume the values shown are described here:
> https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-fscc/3e75d97f-1d0b-4e47-b435-73c513837a57
>
> But my drive (well, all NTFS) does have TRIM enabled:
>
> $ fsutil behavior query disabledeletenotify
> DisableDeleteNotify = 0

Having it enabled and actually active are probably two different things.
Anyway, I can't compare systems with the same hardware and different OS
installations, but I see this flag both as TRUE and FALSE across a
handful of samples with no discernible pattern.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Q+, Q and microQ:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds