linux-ext4 - [PATCH] FIEMAP ioctl

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-Id: <1188382432.3975.21.camel@garfield.linsyssoft.com>
Date:	Wed, 29 Aug 2007 15:43:52 +0530
From:	Kalpak Shah <kalpak@...sterfs.com>
To:	linux-ext4 <linux-ext4@...r.kernel.org>
Cc:	TheodoreTso <tytso@....edu>, Andreas Dilger <adilger@...sterfs.com>
Subject: [PATCH] FIEMAP ioctl

Hi,

Recently there was discussion about an "FIle Extent MAP"(FIEMAP) ioctl for efficiently mapping the extents and holes of a file. This will be many times more efficient than FIBMAP by cutting down the number of ioctls.

This patch implements this ioctl. Ted, in this patch I have used ioctl nunber 10 for FIEMAP. We need to make sure that the ioctl number in our releases and upstream is same. So can you please advise if we can register ioctl no 10 for FIEMAP or if I need to change it?

Let me just mention the the structures and flags used in FIEMAP for people to have a quick review:

struct fiemap_extent {
	__u64	fe_offset; /* offset in bytes for the start of the extent */
	__u64	fe_length; /* length in bytes for the extent */
	__u32	fe_flags;  /* returned FIEMAP_EXTENT_* flags for the extent */
	__u32	fe_lun;	   /* logical device number for extent (starting at 0)*/
};

/*
 * fiemap is not ext4-specific and should be moved into fs.h eventually.
 */

struct fiemap {
	__u64	fm_start;	 /* logical starting byte offset (in/out) */
	__u64	fm_length;	 /* logical length of map (in/out) */
	__u32	fm_flags;	 /* FIEMAP_FLAG_* flags for request (in/out) */
	__u32	fm_extent_count; /* number of extents in fm_extents (in/out) */
	__u64	fm_unused;
	struct fiemap_extent	fm_extents[0];
};

#define	FIEMAP_FLAG_SYNC	0x00000001 /* sync file data before map */
#define	FIEMAP_FLAG_HSM_READ	0x00000002 /* get data from HSM before map */
#define	FIEMAP_FLAG_NUM_EXTENTS	0x00000004 /* return only number of extents */
#define	FIEMAP_FLAG_INCOMPAT	0xff000000 /* error for unknown flags in here */

#define	FIEMAP_EXTENT_HOLE	0x00000001 /* has no data or space allocation */
#define	FIEMAP_EXTENT_UNWRITTEN	0x00000002 /* space allocated, but no data */
#define	FIEMAP_EXTENT_UNMAPPED	0x00000004 /* has data but no space allocation*/
#define	FIEMAP_EXTENT_ERROR	0x00000008 /* mapping error, errno in fe_start*/
#define	FIEMAP_EXTENT_NO_DIRECT	0x00000010 /* cannot access data directly */
#define	FIEMAP_EXTENT_LAST	0x00000020 /* last extent in the file */
#define	FIEMAP_EXTENT_DELALLOC	0x00000040 /* has data but not yet written,
					    * must have EXTENT_UNKNOWN set */
#define	FIEMAP_EXTENT_SECONDARY	0x00000080 /* data (also) in secondary storage,
					    * not in primary if EXTENT_UNKNOWN*/
#define	FIEMAP_EXTENT_EOF	0x00000100 /* if fm_start+fm_len is beyond EOF*/
--

checkpatch.pl has been run on this patch and did not report any errors.

Signed-off-by: Andreas Dilger <adilger@...sterfs.com>
Signed-off-by: Kalpak Shah <kalpak@...sterfs.com>

Thanks,
Kalpak.

View attachment "ext4-fiemap.patch" of type "text/x-patch" (9572 bytes)