On 4 Apr 2018 at 21:01, Todd Chester wrote: Subject: Re: OT:Question on NVME disk direct access? To: users@xxxxxxxxxxxxxxxxxxxxxxx From: Todd Chester <ToddAndMargo@xxxxxxxx> Date sent: Wed, 4 Apr 2018 21:01:15 -0700 Send reply to: Community support for Fedora users <users@xxxxxxxxxxxxxxxxxxxxxxx> > > > 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@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx +------------------------------------------------------------+ Michael D. Setzer II - Computer Science Instructor (Retired) mailto:mikes@xxxxxxxx mailto:msetzerii@xxxxxxxxx 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 _______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
