Woops, I forgot to send this response to the mailing list: Thanks for the information and the explanation. That all makes sense, as I cannot reproduce the non-zero data behaviour and suspect I called fallocate() on an existing file. When I read back freshly fallocated files I only ever get zeros back. Apologies for the confusion. The reason I am trying to create large uninitialized files quickly is that I have a hardware (FPGA) based system which is capable of writing to an SSD at a very fast rate. With software in the loop (managing the OS, file system and IO etc) I am limited to quite low rates (about 1/5 of the hardware performance) as my processor is not very capable. As I typically only write large sequential files, I was pondering whether I could create a large uninitialized file, figure out where it was physically located on the disk, unmount the drive and then let my hardware fill the relevant blocks with data, before handing control back to the software and remounting the drive. This would give me the advantages of a filesystem, without having to implement one in hardware, which would be challenging! This was probably impossible from the get go, as there is no doubt some glaring hole in my understanding of how file systems work! Thanks for the help. On Wed, Mar 8, 2017 at 3:56 PM, Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote: > On Mon, Mar 06, 2017 at 12:02:01PM +0000, Bill McDuck wrote: >> Hello. >> >> I have been testing the performance of XFS with "Flag Unwritten >> Extents" enabled and disabled. > > Why do you disable it? It's been part of the defauly on feature > set for a decade, and manually disabling it will make you run into > completely untested code. There is a reason it's mandatory for v5 > file systems. > >> >> For security reasons I know XFS flags all unwritten extents by >> default, so that uninitialized disk space cannot be read by the user. >> In my application I actually want to have access to this uninitialized >> disk space. I have been modifying the superblocks using xfs_repair to >> enable this functionality. > > Don't do that, it's not supported for a reason. -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
