linux-ext4 - Re: [PATCH 10/47] libext2fs: support BLKZEROOUT/FALLOC_FL_ZERO_RANGE in ext2fs_zero

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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 13 Dec 2014 11:29:17 -0500
From:	Theodore Ts'o <tytso@....edu>
To:	"Darrick J. Wong" <darrick.wong@...cle.com>
Cc:	linux-ext4@...r.kernel.org
Subject: Re: [PATCH 10/47] libext2fs: support BLKZEROOUT/FALLOC_FL_ZERO_RANGE
 in ext2fs_zero_blocks

On Fri, Nov 07, 2014 at 01:51:52PM -0800, Darrick J. Wong wrote:
> +		ret = ioctl(data->dev, BLKZEROOUT, range);
> +		if (ret)
> +			goto err;
> +		if (!(data->flags & IO_FLAG_DIRECT_IO)) {
> +#ifdef POSIX_FADV_DONTNEED
> +			ret = posix_fadvise(data->dev, range[0], range[1],
> +					    POSIX_FADV_DONTNEED);
> +			if (ret == 0)
> +				goto err;
> +#endif
> +#ifdef BLKFLSBUF
> +			ret = ioctl(data->dev, BLKFLSBUF, 0);
> +#endif

Why do you need BLKFLSBUF after calling POSIX_FADV_DONTNEED?  The
problem with BLKFLSBUF is that it has a special meaning for ramdisks,
dating back to when the ramdisk was stored only in the buffer cache, namely:

http://www.memegen.com/meme/hotw4i

We could add yet another special case for the ramdisk, but I'm
seriously wondering whether the use of BLKZEROOUT is worth it.  Sure,
it will speed up mke2fs, but with the advent of metadata checksums, we
can skip clearing the journal and the inode table.

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