[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20141213162917.GH17783@thunk.org>
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
Powered by blists - more mailing lists