On Thu, Mar 02, 2017 at 10:57:51PM -0500, Robert Moskowitz wrote:> > > On 03/02/2017 10:02 PM, Fred Smith wrote: > >On Thu, Mar 02, 2017 at 09:06:52PM -0500, fred roller wrote: > >>On Thu, Mar 2, 2017 at 8:36 PM, Robert Moskowitz <rgm at htt-consult.com> > >>wrote: > >> > >>>dd if=/dev/sdb of=os.img bs=1M count=3210 > >>> > >>I would recommend bs=512 to keep the block sizes the same though not a huge > >>diff just seems to be happier for some reason and add status=progress if > >>you would like to monitor how it is doing. Seems the command you have > >>should work otherwise. > >The dd blocksize has nothing to do with the disk sector size. > > > >the disk sector size is the number of bytes in a minimal read/write > >operation (because the physical drive can't manipulate anything smaller). > > > >the dd blocksize is merely the number of bytes read/written in a > >single read/write operation. (or not bytes, but K, or Kb, or other > >depending on the options you use.) > > > >It makes sense for the bs option in dd to be a multiple of the actual > >disk block/sector size, but isn't even required. if you did dd with a > >block size of, e.g., 27, it would still work, it'd just be stupidly slow. > > Kind of wondered about that. > > So the blocks reported by fdisk is what I should use as the count, > as that matches the drive's real block size? > > thanksif you're copying the entire device, you do not need to tell it how many blocks. just use a large-ish blocksize and let 'er rip. for a single partition, you could use the blocksize and block number you get from fdisk. you would then need to say /dev/sda4, e.g., instead of /dev/sda. when copying an entire drive I tend to use 10M as the blocksize. using a large blocksize just reduces the number of read operations that are needed. that's why a very small blocksize could slow down the copy, as it would require a whole lot more read operations. -- ---- Fred Smith -- fredex at fcshome.stoneham.ma.us ----------------------------- "Not everyone who says to me, 'Lord, Lord,' will enter the kingdom of heaven, but only he who does the will of my Father who is in heaven." ------------------------------ Matthew 7:21 (niv) -----------------------------
On 03/03/2017 07:50 AM, Fred Smith wrote:> On Thu, Mar 02, 2017 at 10:57:51PM -0500, Robert Moskowitz wrote: >> >> On 03/02/2017 10:02 PM, Fred Smith wrote: >>> On Thu, Mar 02, 2017 at 09:06:52PM -0500, fred roller wrote: >>>> On Thu, Mar 2, 2017 at 8:36 PM, Robert Moskowitz <rgm at htt-consult.com> >>>> wrote: >>>> >>>>> dd if=/dev/sdb of=os.img bs=1M count=3210 >>>>> >>>> I would recommend bs=512 to keep the block sizes the same though not a huge >>>> diff just seems to be happier for some reason and add status=progress if >>>> you would like to monitor how it is doing. Seems the command you have >>>> should work otherwise. >>> The dd blocksize has nothing to do with the disk sector size. >>> >>> the disk sector size is the number of bytes in a minimal read/write >>> operation (because the physical drive can't manipulate anything smaller). >>> >>> the dd blocksize is merely the number of bytes read/written in a >>> single read/write operation. (or not bytes, but K, or Kb, or other >>> depending on the options you use.) >>> >>> It makes sense for the bs option in dd to be a multiple of the actual >>> disk block/sector size, but isn't even required. if you did dd with a >>> block size of, e.g., 27, it would still work, it'd just be stupidly slow. >> Kind of wondered about that. >> >> So the blocks reported by fdisk is what I should use as the count, >> as that matches the drive's real block size? >> >> thanks > if you're copying the entire device, you do not need to tell it how > many blocks. just use a large-ish blocksize and let 'er rip. > > for a single partition, you could use the blocksize and block number > you get from fdisk. you would then need to say /dev/sda4, e.g., instead > of /dev/sda. > > when copying an entire drive I tend to use 10M as the blocksize. using > a large blocksize just reduces the number of read operations that are > needed. that's why a very small blocksize could slow down the copy, as > it would require a whole lot more read operations. >Well, I only wanted to copy the used part of the drive which I try to keep small so I can still copy the image to an mSD card if I wish. So I have to supply the amount of the drive to copy. The bs=512 went fast enough, but then I was only copying 3.2GB. thanks for the help.
On 3/3/2017 5:34 AM, Robert Moskowitz wrote:> Well, I only wanted to copy the used part of the drive which I try to > keep small so I can still copy the image to an mSD card if I wish. So > I have to supply the amount of the drive to copy. The bs=512 went > fast enough, but then I was only copying 3.2GB. > > thanks for the help.personally, I would use 'dump' for ext? file systems, and xfsdump for XFS. this *just* backs up the inodes and directories, not raw blocks -- john r pierce, recycling bits in santa cruz