On 2012-06-25, at 12:42 AM, Fredrick wrote: > When calling fallocate on ext4 fs, ext4_fallocate does not initialize > the extents. The whole point of fallocate() is that the extents are uninitialized (i.e. not zero-filled with data, but read back as if they were), and only overwritten with user data as needed. > The extents are allocated only when they are actually > written. This is causing a problem for us. Our programs create many > "write only once" files as large as 1G on ext4 very rapidly at times. > We thought fallocate would solve the problem. But it didnt. > If I change the EXT4_GET_BLOCKS_CREATE_UNINIT_EXT to > just EXT4_GET_BLOCKS_CREATE in the ext4_map_blocks in the ext4_fallocate call, the extents get created in fallocate call itself. This is helping us. This means that if any user reads the fallocate'd file, they will be able to read any old data that was previously written to disk and deleted. This is a big security hole. Also, if the writer of such a file is interrupted for some reason, the file will contain garbage in it. There was a recent patch series "ext4: add an io-tree to track block allocation" that may improve the performance for your case of overwrite of uninitialized files, but it hasn't landed yet. > Now the write throughtput to the disk was close to 98%. When extents were not > initialized, our disk throughput were only 70%. > > Can this change be made to ext4_fallocate? Not if you value data security. That said, it is possible some users value performance over security on systems that have limited access, or do not have any private data on them. If the "io-tree" doesn't fix the performance problem, it may make sense to add a mount option to allow users to specify that uninitialized extents can return old data from disk, but before that happens, I'd really prefer to make the correct behaviour work efficiently. Cheers, Andreas -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
