[PATCH v1 0/1] exfat: Valid Data Length(VDL) ioctl

[PATCH v1 0/1] exfat: Valid Data Length(VDL) ioctl

[David Timber]

To remedy the problems outlines in the commit 1f2b2a3f submitted
previously, I implemented two new ioctls for reading and manipulating
the VDL of files in exFAT fs. For usage example, please review the
link attached.

Link: https://github.com/dxdxdt/exfatprogs/commit/50dc6605216c2dfd30ffcb4f359126b916360d6f

chdosattr and lsdosattr commands are analogous to lsattr and chattr
commands from e2fsprogs. Below is sample output of lsdosattr.

	$ lsdosattr
	----d-        32768            0 .
	------     67108864            = ./full-file
	r-----        32768            = ./readonly
	-h----        32768            = ./hidden
	--s---        32768            = ./system-file
	-h---a      2097152            = ./hidden-archived
	----d-        32768            = ./dir
	------   3221225472   1073741824 ./vdl-a
	------   1073741824         4100 ./vdl-b

where '=' denotes that the VDL is same as isize, '*' denotes no kernel
support(ioctl returned ENOTTY).

Some notable examples of chdosattr usage as follows.

	chdosattr +a   file  # add ARCHIVE to the attribute bitset
	chdosattr -h   file  # clear HIDDEN from the attribute bitset
	chdosattr =ra  file  # set to RO|ARCHIVE
	chdosattr = -R dir   # clear all attributes recursively

Manipulation of the SYSTEM attribute bit is subject to restrictions
already in place within the kernel.

I understand VDL manipulation poses a risk so I decided to submit the
code patch first before doing some documentation work. I'd happily
accept the rejection to the idea of EXFAT_IOC_SET_VALID_DATA.

Further work

NTFS also incorporates DOS attributes and VDL for backward
compatibility in legacy systems albeit NTFS is a sparse-capable
filesystem. For future works, it might be in our interest to implement
the ioctls in the NTFS as well.

Despite the fact that `FAT_IOCTL_*_ATTRIBUTES` ioctls have been
available for a long time now, most userspace programs(most notably
Wine) still rely on the write permission bit to control ATTR_RO. The
only way to control the other attributes(ARCHIVED and HIDDEN) is
through the ioctl.

The VDL ioctl only requires CAP_SYS_ADMIN. For an added layer of
security, perhaps a new SELinux boolean, say
`allow_fat_set_valid_data_ioctl`, should be added.

David Timber (1):
  exfat: Valid Data Length(VDL) ioctl

 fs/exfat/file.c            | 93 ++++++++++++++++++++++++++++++++++++++
 include/uapi/linux/exfat.h | 10 +++-
 2 files changed, 102 insertions(+), 1 deletion(-)

-- 
2.53.0.1.ga224b40d3f.dirty

[PATCH v1 1/1] exfat: Valid Data Length(VDL) ioctl

[David Timber]

Currently, when a file gets truncated written past the VDL, significant
IO delay can occur as the skipped range [VDL, offset) has to be zeroed
out. Some users may find this unacceptible.

Some niche applications(especially embedded systems) may want to
eliminate the delay by manipulating the VDL with the trade-off of
increased risk from garbage data left on the device.

To tackle the IO delay issue, the commit introduces two ioctl,

	#define EXFAT_IOC_GET_VALID_DATA	_IOR('r', 0x14, __u64)
	#define EXFAT_IOC_SET_VALID_DATA	_IOW('r', 0x15, __u64)

which correspond to

	`fsutil file queryvaliddata` command
	SetValidData() WinAPI

respectively. With EXFAT_IOC_GET_VALID_DATA, applications could assess
the delay that may incur and make decisions before seeking past the
VDL to write. With EXFAT_IOC_SET_VALID_DATA, privileged applications
may choose to eliminate the delay and deal with garbage data
themselves.

Signed-off-by: David Timber <dxdt@dev.snart.me>
---
 fs/exfat/file.c            | 93 ++++++++++++++++++++++++++++++++++++++
 include/uapi/linux/exfat.h | 10 +++-
 2 files changed, 102 insertions(+), 1 deletion(-)

diff --git a/fs/exfat/file.c b/fs/exfat/file.c
index 90cd540afeaa..f3b6eca9b1e6 100644
--- a/fs/exfat/file.c
+++ b/fs/exfat/file.c
@@ -449,6 +449,91 @@ static int exfat_ioctl_set_attributes(struct file *file, u32 __user *user_attr)
 	return err;
 }
 
+static int exfat_ioctl_get_valid_data(struct inode *inode, unsigned long arg)
+{
+	u64 valid_size;
+
+	/*
+	 * Tt doesn't really make sense to acquire lock for a getter op but we
+	 * have to stay consistent with the grandfather clause -
+	 * ioctl_get_attributes().
+	 */
+	inode_lock(inode);
+	valid_size = EXFAT_I(inode)->valid_size;
+	inode_unlock(inode);
+
+	return put_user(valid_size, (__u64 __user *)arg);
+}
+
+static int exfat_ioctl_set_valid_data(struct file *file, unsigned long arg)
+{
+	struct inode *inode = file_inode(file);
+	struct exfat_inode_info *ei = EXFAT_I(inode);
+	int err = 0;
+	u64 new_valid_size;
+
+	if (!capable(CAP_SYS_ADMIN))
+		return -EPERM;
+
+	/* No support for dir */
+	if (!S_ISREG(inode->i_mode))
+		return -EOPNOTSUPP;
+
+	err = get_user(new_valid_size, (__u64 __user *)arg);
+	if (err)
+		return err;
+
+	err = mnt_want_write_file(file);
+	if (err)
+		return err;
+
+	inode_lock(inode);
+
+	/* No security check - this is already a privileged op. */
+
+	if (ei->valid_size > new_valid_size || i_size_read(inode) < new_valid_size) {
+		/*
+		 * No change requested. The actual up/down truncation of isize
+		 * is not the scope of the ioctl. SetFileValidData() WinAPI
+		 * treats this case as an error, so we do the same here as well.
+		 */
+		err = -EINVAL;
+		goto out_unlock_inode;
+	}
+	if (ei->valid_size == new_valid_size)
+		/* No op. Don't change mtime. */
+		goto out_unlock_inode;
+
+	ei->valid_size = new_valid_size;
+	/*
+	 * DO NOT invalidate cache here!
+	 *
+	 * The cache incoherency in range [ei->valid_size, new_valid_size) after
+	 * this point is intentional. The point of this ioctl is minimising I/O
+	 * from the shortcoming of FAT/NTFS, not correctness. Neither we nor the
+	 * userspace should care about the garbage data.
+	 */
+
+	/*
+	 * Windows kernel does not update mtime of the file upon successful
+	 * SetFileValidData() call. We think we should - garbage data is still
+	 * data that's part of the contents of the file, so...
+	 */
+	inode_set_mtime_to_ts(inode, inode_set_ctime_current(inode));
+	/*
+	 * Notify the size change although isize didn't actually change. This is
+	 * not conformant but a good measure for any userspace process that
+	 * wishes to get VDL change notification through the standard inotify.
+	 */
+	fsnotify_change(file->f_path.dentry, ATTR_SIZE | ATTR_MTIME);
+	mark_inode_dirty(inode);
+
+out_unlock_inode:
+	inode_unlock(inode);
+	mnt_drop_write_file(file);
+	return err;
+}
+
 static int exfat_ioctl_fitrim(struct inode *inode, unsigned long arg)
 {
 	struct fstrim_range range;
@@ -544,10 +629,17 @@ long exfat_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
 	u32 __user *user_attr = (u32 __user *)arg;
 
 	switch (cmd) {
+	/* inode-specific ops */
 	case FAT_IOCTL_GET_ATTRIBUTES:
 		return exfat_ioctl_get_attributes(inode, user_attr);
 	case FAT_IOCTL_SET_ATTRIBUTES:
 		return exfat_ioctl_set_attributes(filp, user_attr);
+	case EXFAT_IOC_GET_VALID_DATA:
+		return exfat_ioctl_get_valid_data(inode, arg);
+	case EXFAT_IOC_SET_VALID_DATA:
+		return exfat_ioctl_set_valid_data(filp, arg);
+
+	/* fs-wide ops */
 	case EXFAT_IOC_SHUTDOWN:
 		return exfat_ioctl_shutdown(inode->i_sb, arg);
 	case FITRIM:
@@ -556,6 +648,7 @@ long exfat_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
 		return exfat_ioctl_get_volume_label(inode->i_sb, arg);
 	case FS_IOC_SETFSLABEL:
 		return exfat_ioctl_set_volume_label(inode->i_sb, arg);
+
 	default:
 		return -ENOTTY;
 	}
diff --git a/include/uapi/linux/exfat.h b/include/uapi/linux/exfat.h
index 46d95b16fc4b..557785417a2f 100644
--- a/include/uapi/linux/exfat.h
+++ b/include/uapi/linux/exfat.h
@@ -12,7 +12,15 @@
  * exfat-specific ioctl commands
  */
 
-#define EXFAT_IOC_SHUTDOWN _IOR('X', 125, __u32)
+#define EXFAT_IOC_SHUTDOWN		_IOR('X', 125, __u32)
+/* Get the current valid data length(VDL) of a file */
+#define EXFAT_IOC_GET_VALID_DATA	_IOR('r', 0x14, __u64)
+/*
+ * Set the valid data length(VDL) of a file. This is equivalent to
+ * SetValidData() in WinAPI. Due to security implications, CAP_SYS_ADMIN is
+ * required(see capabilities(7)).
+ */
+#define EXFAT_IOC_SET_VALID_DATA	_IOW('r', 0x15, __u64)
 
 /*
  * Flags used by EXFAT_IOC_SHUTDOWN
-- 
2.53.0.1.ga224b40d3f.dirty

Re: [PATCH v1 0/1] exfat: Valid Data Length(VDL) ioctl

[Namjae Jeon]

>
> I understand VDL manipulation poses a risk so I decided to submit the
> code patch first before doing some documentation work. I'd happily
> accept the rejection to the idea of EXFAT_IOC_SET_VALID_DATA.
I am also concerned that this ioctl could expose security data. So,
could you please resubmit the patch excluding
EXFAT_IOC_SET_VALID_DATA ?
Thanks.

[PATCH v2 0/1] exfat: EXFAT_IOC_GET_VALID_DATA ioctl

[David Timber]

On 3/3/26 18:27, Namjae Jeon wrote:
> I am also concerned that this ioctl could expose security data. So,
> could you please resubmit the patch excluding
> EXFAT_IOC_SET_VALID_DATA ?
> Thanks.

Sure.

Expect additional documentation patches in /Documentation and userspace
counterparts and some test units in exfatprogs next week. exfat
definitely deserves its own kernel doc.

David Timber (1):
  exfat: EXFAT_IOC_GET_VALID_DATA ioctl

 fs/exfat/file.c            | 22 ++++++++++++++++++++++
 include/uapi/linux/exfat.h |  4 +++-
 2 files changed, 25 insertions(+), 1 deletion(-)

-- 
2.53.0.1.ga224b40d3f.dirty

[PATCH v2 1/1] exfat: EXFAT_IOC_GET_VALID_DATA ioctl

[David Timber]

When a file in exfat fs gets truncated up or fallocated up, only
additional clusters are allocated and isize updated whilst VDL(valid
data length) remains unchanged. If an application writes to the file
past the VDL, significant IO delay can occur as the skipped range
[VDL, offset) has to be zeroed out before returning to userspace. Some
users may find this caveat unacceptible.

Some niche applications(especially embedded systems) may want to query
the discrepancy between the VDL and isize before doing lseek() and
write() to estimate the delay from implicit zeroring.

The commit introduces a new ioctl,

	#define EXFAT_IOC_GET_VALID_DATA	_IOR('r', 0x14, __u64)

which correspond to

	`fsutil file queryvaliddata ...`

command in Windows.

With the new ioctl, applications could assess the delay that may incur
and make decisions accordingly before seeking past the VDL to write.

Signed-off-by: David Timber <dxdt@dev.snart.me>
---
 fs/exfat/file.c            | 22 ++++++++++++++++++++++
 include/uapi/linux/exfat.h |  4 +++-
 2 files changed, 25 insertions(+), 1 deletion(-)

diff --git a/fs/exfat/file.c b/fs/exfat/file.c
index 90cd540afeaa..a13044a7065a 100644
--- a/fs/exfat/file.c
+++ b/fs/exfat/file.c
@@ -449,6 +449,22 @@ static int exfat_ioctl_set_attributes(struct file *file, u32 __user *user_attr)
 	return err;
 }
 
+static int exfat_ioctl_get_valid_data(struct inode *inode, unsigned long arg)
+{
+	u64 valid_size;
+
+	/*
+	 * Doesn't really make sense to acquire lock for a getter op but we have
+	 * to stay consistent with the grandfather clause -
+	 * ioctl_get_attributes().
+	 */
+	inode_lock(inode);
+	valid_size = EXFAT_I(inode)->valid_size;
+	inode_unlock(inode);
+
+	return put_user(valid_size, (__u64 __user *)arg);
+}
+
 static int exfat_ioctl_fitrim(struct inode *inode, unsigned long arg)
 {
 	struct fstrim_range range;
@@ -544,10 +560,15 @@ long exfat_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
 	u32 __user *user_attr = (u32 __user *)arg;
 
 	switch (cmd) {
+	/* inode-specific ops */
 	case FAT_IOCTL_GET_ATTRIBUTES:
 		return exfat_ioctl_get_attributes(inode, user_attr);
 	case FAT_IOCTL_SET_ATTRIBUTES:
 		return exfat_ioctl_set_attributes(filp, user_attr);
+	case EXFAT_IOC_GET_VALID_DATA:
+		return exfat_ioctl_get_valid_data(inode, arg);
+
+	/* fs-wide ops */
 	case EXFAT_IOC_SHUTDOWN:
 		return exfat_ioctl_shutdown(inode->i_sb, arg);
 	case FITRIM:
@@ -556,6 +577,7 @@ long exfat_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
 		return exfat_ioctl_get_volume_label(inode->i_sb, arg);
 	case FS_IOC_SETFSLABEL:
 		return exfat_ioctl_set_volume_label(inode->i_sb, arg);
+
 	default:
 		return -ENOTTY;
 	}
diff --git a/include/uapi/linux/exfat.h b/include/uapi/linux/exfat.h
index 46d95b16fc4b..da65aef416cc 100644
--- a/include/uapi/linux/exfat.h
+++ b/include/uapi/linux/exfat.h
@@ -12,7 +12,9 @@
  * exfat-specific ioctl commands
  */
 
-#define EXFAT_IOC_SHUTDOWN _IOR('X', 125, __u32)
+#define EXFAT_IOC_SHUTDOWN		_IOR('X', 125, __u32)
+/* Get the current valid data length(VDL) of a file */
+#define EXFAT_IOC_GET_VALID_DATA	_IOR('r', 0x14, __u64)
 
 /*
  * Flags used by EXFAT_IOC_SHUTDOWN
-- 
2.53.0.1.ga224b40d3f.dirty

Re: [PATCH v2 1/1] exfat: EXFAT_IOC_GET_VALID_DATA ioctl

[Namjae Jeon]

> diff --git a/include/uapi/linux/exfat.h b/include/uapi/linux/exfat.h
> index 46d95b16fc4b..da65aef416cc 100644
> --- a/include/uapi/linux/exfat.h
> +++ b/include/uapi/linux/exfat.h
> @@ -12,7 +12,9 @@
>   * exfat-specific ioctl commands
>   */
>
> -#define EXFAT_IOC_SHUTDOWN _IOR('X', 125, __u32)
> +#define EXFAT_IOC_SHUTDOWN             _IOR('X', 125, __u32)
> +/* Get the current valid data length(VDL) of a file */
> +#define EXFAT_IOC_GET_VALID_DATA       _IOR('r', 0x14, __u64)
It uses 'r' (0x14), which is shared with the FAT-fs. However, since
VDL (Valid Data Length) is a specific feature of exFAT, using the 'r'
range might lead to potential conflicts with future FAT updates or
Android-specific extensions. What do you think about having its own
dedicated magic number (e.g., EXFAT_IOCTL_MAGIC : 0xEF) for
exFAT-specific extensions?

Re: [PATCH v2 1/1] exfat: EXFAT_IOC_GET_VALID_DATA ioctl

[David Timber]

> What do you think about having its own
> dedicated magic number (e.g., EXFAT_IOCTL_MAGIC : 0xEF) for
> exFAT-specific extensions?
Absolutely. I was expecting this discusstion about the ioctl magic.

https://lwn.net/Articles/897202/

My intuition was that the 16-bit namespace is already quite crowded
hence my initial decision to add to the existing FAT magic. If the new
magic could be afforded, that's definitely the right way forward.
However, the ioctl namespace is becoming a scarce commodity in Linux.
(ex)FAT is a simple filesystem by design, so there's not a whole lot to
it. Perhaps it doesn't really deserve its own ioctl magic. I'd like to
leave it up to the skillful maintainers.

FYI, the room to grow(TODO) for exFAT/NTFS on my list include(somewhat
related to the topic, not in particular order):

1. FIEMAP support for 512-bytes-per-sector flash memory drives with
capacities over 2TB(512 * 2^32). Don't worry - exFAT works fine with 4k
advanced format and > 2TB 512B LBA. This is only for filefrag report
2. VDL in NTFS. Although different in on-disk format, the behaviour
apparent to userspace is identical (share the ioctl?)
3. exFAT/NTFS fs-level encryption(EFS, similar to Ext4 encryption) which
may require a set of ioctls for key management - if allowed, that is(EFS
could be patent/licence protected)
4. bad cluster tagging(offline or online) and some ioctl facilities to
query info about bad clusters

I'd say, exFAT and NTFS specs are designed maintained by the same
organisation and that often leads to new filesystem features ending up
similar or almost identical. So, yes, assign a new magic but maybe share
it between exFAT and NTFS, if that doesn't break any rules I'm not aware of.

Davo

Re: [PATCH v2 1/1] exfat: EXFAT_IOC_GET_VALID_DATA ioctl

[Namjae Jeon]

On Sat, Mar 7, 2026 at 5:05 PM David Timber <dxdt@dev.snart.me> wrote:
>
> > What do you think about having its own
> > dedicated magic number (e.g., EXFAT_IOCTL_MAGIC : 0xEF) for
> > exFAT-specific extensions?
> Absolutely. I was expecting this discusstion about the ioctl magic.
>
> https://lwn.net/Articles/897202/
>
> My intuition was that the 16-bit namespace is already quite crowded
> hence my initial decision to add to the existing FAT magic. If the new
> magic could be afforded, that's definitely the right way forward.
> However, the ioctl namespace is becoming a scarce commodity in Linux.
> (ex)FAT is a simple filesystem by design, so there's not a whole lot to
> it. Perhaps it doesn't really deserve its own ioctl magic. I'd like to
> leave it up to the skillful maintainers.
>
> FYI, the room to grow(TODO) for exFAT/NTFS on my list include(somewhat
> related to the topic, not in particular order):
Sounds great:)
>
> 1. FIEMAP support for 512-bytes-per-sector flash memory drives with
> capacities over 2TB(512 * 2^32). Don't worry - exFAT works fine with 4k
> advanced format and > 2TB 512B LBA. This is only for filefrag report
Since we can find out the unwritten area through fiemap ioctl(i.e. if
fiemap ioctl is supported), wouldn't vdl ioctl be unnecessary?

> 2. VDL in NTFS. Although different in on-disk format, the behaviour
> apparent to userspace is identical (share the ioctl?)
> 3. exFAT/NTFS fs-level encryption(EFS, similar to Ext4 encryption) which
> may require a set of ioctls for key management - if allowed, that is(EFS
> could be patent/licence protected)
> 4. bad cluster tagging(offline or online) and some ioctl facilities to
> query info about bad clusters
>
> I'd say, exFAT and NTFS specs are designed maintained by the same
> organisation and that often leads to new filesystem features ending up
> similar or almost identical. So, yes, assign a new magic but maybe share
> it between exFAT and NTFS, if that doesn't break any rules I'm not aware of.
Okay, And if we allocate new ioctl number for this, we need to update
Documentation/userspace-api/ioctl/ioctl-number.rst

Thanks.
>
> Davo

Re: [PATCH v2 1/1] exfat: EXFAT_IOC_GET_VALID_DATA ioctl

[David Timber]

On 3/10/26 08:28, Namjae Jeon wrote:
> Since we can find out the unwritten area through fiemap ioctl(i.e. if
> fiemap ioctl is supported), wouldn't vdl ioctl be unnecessary?
Good point. That's one way to estimate VDL, but not the exact VDL.
FIEMAP is in block unit. The last written cluster does not necessarily
have all the bytes written to it. AFAIK, struct fiemap_extent does not
have the info on the actual bytes in use. Also, the info is already
available through st->st_blocks. Besides, FIEMAP is not that efficient
when the file is huge and heavily fragmented. The userspace would have
to do multiple ioctl calls to get to the unwritten extent.

The whole point of the new ioctl is because the VDL does not fit into
any standard userspace interface. i.e. the case where

    vdl < st->st_size <= st->st_blocks

> Okay, And if we allocate new ioctl number for this, we need to update
> Documentation/userspace-api/ioctl/ioctl-number.rst
Sure. Will report back in a few days.

Regards,
Davo