On 4 Apr 2018 at 21:01, Todd Chester wrote:
Subject: Re: OT:Question on NVME disk direct access?
To: users(a)lists.fedoraproject.org
From: Todd Chester <ToddAndMargo(a)zoho.com>
Date sent: Wed, 4 Apr 2018 21:01:15 -0700
Send reply to: Community support for Fedora users
<users(a)lists.fedoraproject.org>
On 04/02/2018 11:30 AM, Michael D. Setzer II wrote:
> I'm the maintainer of the G4L disk imaging project since 2004, and I use
> Fedora as the build platform. Currently using Fedora 27.
>
> Have an issue from a user that has me baffled, so am hoping someone here
> might provide some guidance.
>
> The program boots a linux kernel, and basically uses dd to copy the
> disk/partitions thru a compression program and creates an image file on ftp
> server or local device.
>
> I don't have any physical nvme disks, but using virtualbox I created a 4M
> disk, and 2 - 2M partitions within it. In testing that, the 4M disk compresses to
> a 30K file, and the 2M partitions compress to about 15K each. That is what is
> expected with cleared partitions.
>
> The user though, with a real 256G disk doesn't seem to get any compression
> of the disk or partitions. Them resulting images are close to the same size as
> the disks or partitions??
>
> He can mount the partitions and see the files, so there must be something
> going on that I don't see?
>
> Would think that accessing the /dev/nvme0n1 or partitions /dev/nvme0n1p1
> thru p5 would act the same as accessing /dev/sda or /dev/sdax partitions.
>
> The images that are created pass the compression program test, so it is
> reading data, but in some form that doesn't compress much, and user has
> used a program to clear the unused space?
>
> Thanks for your time, and any ideals.
Hi Michael,
This probably won't help as I don't entirely understand your
question.
My FC27 system has a LUKS encrypted 1 GB NVMe drive. I clone
the drive to a mechanical drive as a poor man's RAID1. NVMe
drives don't do RAID1.
My first attempt, was booting off a Live USB and do a "dd".
It was a disaster. Took 14 hours and did not work in the
end.
Then I switched Clone Zilla to do the clone and it has worked
perfectly about 5 times now. The mechanical clone drive boots
perfectly too.
Clone Zilla only takes 1:24 to clone. It uses dd to clone LUKS
drives, so who knows why Clone Zilla's works and mine does not.
-T
________________________________
Thanks for the reply. There are lots of issues with doing cloning.
Usually, doing a disk clone gets arround issues where the boot loader is
using the blkid, since it makes the blikids for the partitions the same. Problem
with that thou is that you can't have to disks in the same machine with the
same blkids. Once cloned a disk, and then rebooted it to the OS without
disconnecting, and for some reason, it mounted some partitions from the first
disk, and others from the second?
Same issue with the boot loaders using the /dev/sdx option. If you clone a
disk on /dev/sda to /dev/sdb it works fine, but if you remove sda to test if it
will boot, it will not since second disk with have sdb instead of the sda. Have
to switch cables, or change boot order in bios.
Contacted the person in charge of the nvme program, and he says it should
work as it does with the virtualbox test I did.
User was using a windows program called eraser to clear the drive, but from
what I have just found it seems to be a security eraser, and rights random
data to the unused space as contrasted to writing nulls. Think the program
was probable working just fine, but with completely random data the lzop
compression doesn't work well. About twice the speed of gzip but 10% larger
images. I could take a 1T disk, and compress it down to a 40G file with
Windows 10 and Fedora 25 on it.
My classroom setup also, had and NFTS clone image file on a separate
partitions, and had an grub boot option, that would reimage the 160G
Windows 10 partition in about 12 minutes. About a 20G image file.
Have a program on the g4l disk that will zero out the unused space, so have
asked the user to try using that to clean disk, and then make image.
Hopefully, that will result in the expected compression.
Thanks again for the info.
_______________
users mailing list -- users(a)lists.fedoraproject.org
To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
+------------------------------------------------------------+
Michael D. Setzer II - Computer Science Instructor (Retired)
mailto:mikes@guam.net
mailto:msetzerii@gmail.com
Guam - Where America's Day Begins
G4L Disk Imaging Project maintainer
http://sourceforge.net/projects/g4l/
+------------------------------------------------------------+
http://setiathome.berkeley.edu (Original)
Number of Seti Units Returned: 19,471
Processing time: 32 years, 290 days, 12 hours, 58 minutes
(Total Hours: 287,489)
BOINC@HOME CREDITS
ROSETTA 65132161.613216 | ABC 16613838.513356
SETI 109336776.035164 | EINSTEIN 141004554.999240