On 4 Apr 2018 at 21:01, Todd Chester wrote:

Subject:                Re: OT:Question on NVME disk direct access?
To:                     users@lists.fedoraproject.org
From:                   Todd Chester <toddandma...@zoho.com>
Date sent:              Wed, 4 Apr 2018 21:01:15 -0700
Send reply to:          Community support for Fedora users 

> 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. 
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@lists.fedoraproject.org
> To unsubscribe send an email to users-le...@lists.fedoraproject.org

 Michael D. Setzer II - Computer Science Instructor (Retired)     
 Guam - Where America's Day Begins                        
 G4L Disk Imaging Project maintainer 

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)


ROSETTA      65132161.613216 | ABC          16613838.513356
SETI        109336776.035164 | EINSTEIN    141004554.999240
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org

Reply via email to