DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:subject:to:references:from:message-id:date
	:mime-version:in-reply-to:content-type; q=dns; s=default; b=u89C
	0OnGVYxehLc0mQzs2Jn1DDbniB1pOxhrLbavCVgB+yuQoZalBBbRUdHO9/HiQgqh
	VZrNSaEZlf93bI5BJHXtyHWdIQbeOwT47rmnYCffyTHIqhIr96NSjbZQzQmsuszO
	Os7azLYzi+r1ZizDCs5tUbVvmb/dz+2xLtpqKfk=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Subject: Re: Is a disk image created within dd "safe"?
To: cygwin AT cygwin DOT com
References: <CA+imRYKfrvgVWUSh4=9tsF=QxjKGfPoiE-nRfVF7rbWO1v-b8A AT mail DOT gmail DOT com> <CA+imRYLmnThTV-7=JQ_viDLk65HeO+2sUdxN+ThGkML6=k=iQw AT mail DOT gmail DOT com>
From: Eric Blake <eblake AT redhat DOT com>
Openpgp: url=http://people.redhat.com/eblake/eblake.gpg
Message-ID: <55E772CF.4070807@redhat.com>
Date: Wed, 2 Sep 2015 16:06:07 -0600
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0
MIME-Version: 1.0
In-Reply-To: <CA+imRYLmnThTV-7=JQ_viDLk65HeO+2sUdxN+ThGkML6=k=iQw@mail.gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="kQTtDJhsw3OCpnrdTpoi7v3nslhtAV88n"

--kQTtDJhsw3OCpnrdTpoi7v3nslhtAV88n
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 09/02/2015 03:57 PM, Clint Olsen wrote:

> I'm also interested in generating images to preserve the entire disk.
> What I'm wondering is whether doing this on a live system through
> Cygwin would produce a safe, bootable disk image or if the the APIs
> that Cygwin has to use or having the disk mounted would make this
> unreliable?

The answer is the same on non-cygwin systems.  ANY attempt to
sequentially read a disk while some other entity may be actively
modifying the same disk is doomed to capture incomplete (and probably
unusable) state.

>=20
> A friend speculated that dd might complain about open files or
> some-such thing. I went and tried it on /dev/sda and it seemed to work
> without complaining.

dd won't complain, but it also won't capture an accurate image.  There
is a difference between the block layer (read each sector of the disk,
regardless of what is happening in other sectors due to file system
activity) and the file system layer (read multiple files one at a time,
regardless of which sectors the file system currently maps those files
to).  The only safe way to use dd to clone a disk is if the disk is not
currently mounted by any filesystem that might be actively modifying
sectors in the block device.

There are various solutions that CAN capture an accurate point-in-time
disk snapshot.  For example, on Linux, you can use LVM and create an LVM
snapshot, which separates all data at a given point in time from all
further changes to the live disk, so that you can then do a background
task that reads the snapshot without worrying about data going
inconsistent, and so that the guest can continue to run with the live
overlay.  Many SAN storage vendors sell specific solutions along these
lines, and it is also a hot topic with virtual machine solutions.  But
in every case, these sorts of solutions require additional storage
hierarchies (they are not copying /dev/sda directly, so much as exposing
/dev/sda as a layer on top of other storage such that the actual
snapshot operation utilizes that other storage for the background
copy-on-write overlay magic).

--=20
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


--kQTtDJhsw3OCpnrdTpoi7v3nslhtAV88n
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
Comment: Public key at http://people.redhat.com/eblake/eblake.gpg
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBCAAGBQJV53LPAAoJEKeha0olJ0Nq8B8H/RAUjxDmRvHHHDSq3tJpJAFx
fG7WzV59dNj9pXhx8DKs08At3YbslgQiieBOjoREzZv6wTCGnZ0gDHS7iJ744Ryr
HwRxjV1+rUpk3F13F+62L4EwmrjbhuCbRBZiwKatiMnxoXlefeMyKIaem8qHrT55
E2GZm9BzEULRFhDd3hjFvZXY8JRPxK7DJIg5Kx5HB0hL0/JlixLLpga7mlu0ANr/
x/pUUvqm3o2fib+gYazaYCIIqBP6dgfavMl77UFREdoalYRbmWhz5MRb+VJNSTIJ
XS1Oz7/8ww17g9cheGAi/jvT6obUDPAeYRvKlbXitGo4kAeo2mopWfp0/aQyLIo=
=jEyd
-----END PGP SIGNATURE-----

--kQTtDJhsw3OCpnrdTpoi7v3nslhtAV88n--