All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Antoine Beaupré" <anarcat@orangeseeds.org>
To: Sitsofe Wheeler <sitsofe@gmail.com>
Cc: "fio@vger.kernel.org" <fio@vger.kernel.org>
Subject: Re: could fio be used to wipe disks?
Date: Thu, 16 Mar 2017 08:30:18 -0400	[thread overview]
Message-ID: <87shmd1k11.fsf@curie.anarc.at> (raw)
In-Reply-To: <CALjAwxjrNpTQTitcZCFA205m6mtE04OC_R_zmsK593hEUK3bPg@mail.gmail.com>

On 2017-03-16 07:42:48, Sitsofe Wheeler wrote:
> Hi,
>
> 1. It will try and use the whole area of the disk but if fio's
> blocksize turns out not to the same as the disk's block size it may
> miss the very end of the disk.

I see.

> Also if an error is encountered fio may
> stop part way through and fail to overwrite the rest of the data.

That's not much of an issue for me.

> you're not paranoid about disk wiping then it is unlikely that fio
> will be any faster than doing something like
> dd if=/dev/zero of=/dev/mydisk bs=1M oflag=direct

The idea is not to be fast, but to two the two things at once: a more
extensive stress test *and* a disk wipe, in optimal time.

> Bear in mind that if you're worried about wiping disks properly you
> will have to write particular pattern over the disk.

Yeah, I know about nwipe and everything. As I mentioned originally, I am
not sure this is in the scope of my project...

> Further it may not easier than you think to get at stale internal
> mappings the "disk" might have which is why you use SECURE ERASE on
> SSDs. fio does none of this.

... I also mentioned I was aware of SSD specifics, thanks. :)

> Since you mentioned stress you may want to look at using a deeper
> iodepth with the libaio engine (assuming you're on Linux, other
> platforms have asynchronous engines too) and only doing the sync at
> the end.

Even after reading this:

http://fio.readthedocs.io/en/latest/fio_doc.html#i-o-depth

I don't quite understand what iodepth does or how to use it. Could you
expand on this?

> 2. What you are proposing is very dangerous. Assuming the filesystem
> is unmounted you and you wanted to do writes you would need to read
> the data and then write that same data back but fio has no facility
> for such a thing at present. If the filesystem is mounted then I think
> what you're asking for is impossible without introducing the
> possibility of filesystem corruption.

Right, that's what I figured as well, thanks for the confirmation!

A.

-- 
The Net treats censorship as damage and routes around it.
                         - John Gilmore

  reply	other threads:[~2017-03-16 12:39 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-15 21:42 could fio be used to wipe disks? Antoine Beaupre
2017-03-16  7:42 ` Sitsofe Wheeler
2017-03-16 12:30   ` Antoine Beaupré [this message]
2017-03-16 17:35     ` Sitsofe Wheeler
     [not found]   ` <CAGpXXZ+bWSkOp3KqUvycgHY1gaonriGX95-7tUQ-nND-sGbaeA@mail.gmail.com>
2017-03-16 17:14     ` Sitsofe Wheeler

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87shmd1k11.fsf@curie.anarc.at \
    --to=anarcat@orangeseeds.org \
    --cc=fio@vger.kernel.org \
    --cc=sitsofe@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.