Message 3 of 6
28 Jan 18 21:31
Join Date: 12 Sep 2007
Posts To This List: 123
ReFS and 128 bit file ID
The 64 bit one is indeed for compatibility.
NTFS has a single, 48 bit volume wide file index, plus a 16 bit sequence
number for that index, in a 64 bit value. This means that it is willing
to reuse file identifiers, and have collisions.
ReFS has a directory identifier and a file identifier in its file ID,
and these are monotonically increasing and will never be reused for the
lifetime of the volume. Unfortunately 64 bits volume wide isn't really
enough to ensure that a production volume will never "run out" of
identifiers, either in terms of directories-per-volume or
files-per-directory. 64 bit support is there to provide limited
compatibility until software can be reworked to use larger identifiers,
but if the goal is to run software on a real ReFS volume, using 128 bit
identifiers is a very good idea.
As has been noted, 128 bit identifiers also now work on NTFS.
Unfortunately most real world software still needs 64 bit identifier
support because it needs to run on older version of Windows where this
support is not present. IIRC NTFS has 128 bit ID support in 2012
R2/8.1, so at some point 64 bit ID support can be retired altogether.
On 01/26/2018 11:57 PM, Gabriel Bercea wrote:
> I am assuming the 64 bit one works for backwards compatibility. ReFs in
> many ways is still similar to NTFS. Imagine how many apps and drivers
> out there may do things based on the 64 bit file id, but, and this is a
> crucial but without checking the file system on the volume.
> I may of course be wrong and there would be a deeper reason than this,
> for example some part of the ReFs implementation which is NTFS with some
> new additions depended on this 64 bit file id and they could not remove
> it yet.
> Now again, looking at how you approach this, you seem to be tending to
<...excess quoted lines suppressed...>