Re: punching holes in files

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 1 Nov 2007, at 19:16, Steve French wrote:
madvise_remove (in Linux) is used to free the backing store associated
with pages (punching a hole in a file).   This is one of the vfs
operations that we do not send over the wire to Samba (so this call
would return -ENOSYS locally).   Any thoughts on whether this could be
done with an obscure SetFileInfo level or FCNTL or whether it is worth
adding to the CIFS POSIX Extensions?

Don't know about SMB/CIFS but on Windows locally you would need to first set the file sparse, and then to punch the hole. These two things are accomplished like so on Windows (STARTING_OFFSET is the first byte of the hole to be punched and END_OFFSET is the first byte after the hole to be punched):

	HANDLE f; // This is obtained from a CreateFile() call...
	DWORD bw;

	/* Set file sparse. */
if (!DeviceIoControl(f, FSCTL_SET_SPARSE, NULL, 0, NULL, 0, &bw, NULL)) {
		// Failed.
		return 1;
	}

	FILE_ZERO_DATA_INFORMATION z;

	/* Create a hole. */
	z.FileOffset.QuadPart = STARTING_OFFSET;
	z.BeyondFinalZero.QuadPart = END_OFFSET;
if (!DeviceIoControl(f, FSCTL_SET_ZERO_DATA, &z, sizeof(z), NULL, 0, &bw, NULL)) {
		// Failed.
		return 1;
	}

A second interesting question is whether to implement fallocate over
the wire.  sys_fallocate takes a range (and also a flag which
indicates whether to extend the size beyond end of file).
SET_FILE_ALLOCATION_INFO takes a size field rather than a range.  For
the case of the range starting at zero, we could simply call Trans2
set pathinfo (or file info) with SET_FILE_ALLOCATION_INFO.   Should we
add a CIFS POSIX Extension operation for this too?

By the way it looks like OCFS2 (not just ext4) implement these.


Again, I don't know about SMB/CIFS but Windows locally supports this, too. To pre-allocate some space without changing the file size (i.e. this only allocates space on disk, assigns it to the file, and changes the allocated_size on NTFS appropriately but does not change the data_size), one would call (note BYTE_OFFSET_IN_FILE_TO_PREALLOCATE_TO is the logical file offset to which to pre-allocate to):

	HANDLE f; // This is obtained from a CreateFile() call...
	FILE_ALLOCATION_INFO ai;

	ai.AllocationSize.QuadPart = BYTE_OFFSET_IN_FILE_TO_PREALLOCATE_TO;
if (!SetFileInformationByHandle(f, FileAllocationInfo, &ai, sizeof(ai))) {
		// Failed.
		return 1;
	}

Hope this is of some use to use...

Best regards,

	Anton
--
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer, http://www.linux-ntfs.org/

-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux