On 9/20/13 11:42 AM, David Sterba wrote:
> The message about trim was printed unconditionally, we should check if
> trim is supported at all.
Good idea, but I wonder if there's any risk that discard(0,0) will ever
be optimized away on the kernel side & pass unconditionally?
I was thinking we could get this from blkid, but maybe not.
In the meantime it does do the right thing, so:
Reviewed-by: Eric Sandeen <sandeen@xxxxxxxxxx>
> Signed-off-by: David Sterba <dsterba@xxxxxxx>
> ---
> utils.c | 13 ++++++++-----
> 1 file changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/utils.c b/utils.c
> index 5fa193b..6c74654 100644
> --- a/utils.c
> +++ b/utils.c
> @@ -597,13 +597,16 @@ int btrfs_prepare_device(int fd, char *file, int zero_end, u64 *block_count_ret,
> }
>
> if (discard) {
> - fprintf(stderr, "Performing full device TRIM (%s) ...\n",
> - pretty_size(block_count));
> /*
> - * We intentionally ignore errors from the discard ioctl. It is
> - * not necessary for the mkfs functionality but just an optimization.
> + * We intentionally ignore errors from the discard ioctl. It
> + * is not necessary for the mkfs functionality but just an
> + * optimization.
> */
> - discard_blocks(fd, 0, block_count);
> + if (discard_blocks(fd, 0, 0) == 0) {
> + fprintf(stderr, "Performing full device TRIM (%s) ...\n",
> + pretty_size(block_count));
> + discard_blocks(fd, 0, block_count);
> + }
> }
>
> ret = zero_dev_start(fd);
>
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
