All of lore.kernel.org
 help / color / mirror / Atom feed
From: Douglas Gilbert <dgilbert@interlog.com>
To: linux-scsi <linux-scsi@vger.kernel.org>
Subject: [LSF/MM TOPIC] Sparseness in storage
Date: Wed, 02 Feb 2011 12:07:23 -0500	[thread overview]
Message-ID: <4D498F4B.3050207@interlog.com> (raw)

There are a lot of zeros out there. Efficient use of sparseness
involves techniques to detect large quantities of zeros in
advance rather than just reading them all. And on the write side
there are standard techniques to append zeros to a file without
actually writing them.

Seems a damn shame to read a terabyte of zeros and then write them
to another device or file. Carrying the idea further: if we know
random data has no meaning *** and we are asked to copy it,
why not "write" zeros to the output file?

Over the last few years various commands have been added to the
SCSI and ATA command sets to better handle sparseness (and
trim/unmap/write_same can be viewed in this light). File systems
are improving their sparseness handling as well, with Linux
playing "catch up" to NTFS in this regard (e.g. the new
FALLOC_FL_PUNCH_HOLE flag in fallocate() ).

So I am proposing a discussion of the:
   - existing SCSI commands to support sparseness
   - existing ATA commands to support sparseness
   - suggestions for more sparseness support to be
     added to the SCSI and ATA command sets
   - user space tools that support sparseness
   - file system support for sparseness

Perhaps the latter point should involve the file system track as
well.

Doug Gilbert
20100202


*** For example: after ATA CRYPTO SCRAMBLE EXT command (which
     is one of the "sanitize device" commands and is fast) the
     data read will be random and meaningless. If the disk does
     "read zero after trim" why not follow the scramble with a
     trim/unmap of the whole disk?

             reply	other threads:[~2011-02-02 17:07 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-02 17:07 Douglas Gilbert [this message]
2011-02-03  2:23 ` [LSF/MM TOPIC] Sparseness in storage Christoph Hellwig
2011-02-03 14:40   ` Douglas Gilbert
2011-02-06 22:18 ` Shyam_Iyer
2011-02-06 23:58 ` Richard Sharpe

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=4D498F4B.3050207@interlog.com \
    --to=dgilbert@interlog.com \
    --cc=linux-scsi@vger.kernel.org \
    /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.