[opensuse] duplicating current drive to new drive via usb and dd?
All, I have had a few bad blocks show up on my laptop hard-drive. I have a new drive (larger) and I would like to duplicate/clone my entire drive by attaching the new drive to the laptop through the usb port, booting from the openSuSE install disk and then using dd to clone the old drive to new. Having never attempted a clone-by-usb, I don't even know if that is possible with the software on the install CD. So before spending a couple of hours to find out it won't work, I'll ask the brain-trust: (1) Does the install CD provide sufficient USB connection capability to attach a second drive by USB and make the device available to receive the contents of the original using dd? (2) presuming I can get the usb drive up as /dev/sdb (or wherever it end up), can anyone suggest any further optimizations for the dd clone beyond: dd if=/dev/sda of=/dev/sdb bs=4096 conv=notrunc,noerror,sync -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 07/04/2014 05:37 PM, David C. Rankin wrote:
All,
I have had a few bad blocks show up on my laptop hard-drive. I have a new drive (larger) and I would like to duplicate/clone my entire drive by attaching the new drive to the laptop through the usb port, booting from the openSuSE install disk and then using dd to clone the old drive to new. Having never attempted a clone-by-usb, I don't even know if that is possible with the software on the install CD. So before spending a couple of hours to find out it won't work, I'll ask the brain-trust:
(1) Does the install CD provide sufficient USB connection capability to attach a second drive by USB and make the device available to receive the contents of the original using dd?
(2) presuming I can get the usb drive up as /dev/sdb (or wherever it end up), can anyone suggest any further optimizations for the dd clone beyond:
dd if=/dev/sda of=/dev/sdb bs=4096 conv=notrunc,noerror,sync
I use Clonezilla booted from a flash drive, has worked for everything I have copied so far. Mike. -- OpenSuse Desktop (13.1) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2014-07-04 23:37, David C. Rankin wrote:
All,
I have had a few bad blocks show up on my laptop hard-drive. I have a new drive (larger) and I would like to duplicate/clone my entire drive by attaching the new drive to the laptop through the usb port, booting from the openSuSE install disk and then using dd to clone the old drive to new. Having never attempted a clone-by-usb, I don't even know if that is possible with the software on the install CD. So before spending a couple of hours to find out it won't work, I'll ask the brain-trust:
(1) Does the install CD provide sufficient USB connection capability to attach a second drive by USB and make the device available to receive the contents of the original using dd?
(2) presuming I can get the usb drive up as /dev/sdb (or wherever it end up), can anyone suggest any further optimizations for the dd clone beyond:
dd if=/dev/sda of=/dev/sdb bs=4096 conv=notrunc,noerror,sync
Ok, I have done this before, but to disks of the exact same size. First, don't use the install CD, unless you can not download anything else. Instead, from the openSUSE site, download the XFCE CD, which is not an installation image, but a rescue image. It does not have *office tools, nor installation tools, to save space, and instead has other tools indicated for this kind of work. If installed on a USB stick, since version 13.1, you get a persistent filesytem, so you can even install further packages or save files. It is very nice. Then, as you have bad sectors, 'dd' is a bad idea. Instead, use 'dd_rhelp' or 'ddrescue'. They are very similar tools, but the syntax is different. I think the xfce image contains the first version. Any of those tools will make a proper image, either of single partitions, or of full disks, skipping the bad blocks, where dd may get stuck for long time. The strategy is to copy as soon as possible the good sectors, then try to copy the bad regions. This might be done in hours, or days, till you stop. For instance, after a reasonable time, it say that 99.99% is copied. The rest may take a very long time, depending on the damage. You can then decide to stop it there, and be happy with that 99%. (dd_rescue is used by dd_rhelp; don't use it directly; it is possible, but more cumbersome for this purpose) Another tool is clonezilla, using its own boot CD. It is text mode, and very good for cloning disks and partitions, conserving space, and, I believe, expanding the destination space if wanted. However, I have never tried it on a damaged disk. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/04/2014 05:00 PM, Carlos E. R. wrote:
On 2014-07-04 23:37, David C. Rankin wrote:
All,
I have had a few bad blocks show up on my laptop hard-drive. I have a new drive (larger) and I would like to duplicate/clone my entire drive by attaching the new drive to the laptop through the usb port, booting from the openSuSE install disk and then using dd to clone the old drive to new. Having never attempted a clone-by-usb, I don't even know if that is possible with the software on the install CD. So before spending a couple of hours to find out it won't work, I'll ask the brain-trust:
(1) Does the install CD provide sufficient USB connection capability to attach a second drive by USB and make the device available to receive the contents of the original using dd?
(2) presuming I can get the usb drive up as /dev/sdb (or wherever it end up), can anyone suggest any further optimizations for the dd clone beyond:
dd if=/dev/sda of=/dev/sdb bs=4096 conv=notrunc,noerror,sync
Ok, I have done this before, but to disks of the exact same size.
First, don't use the install CD, unless you can not download anything else. Instead, from the openSUSE site, download the XFCE CD, which is not an installation image, but a rescue image. It does not have *office tools, nor installation tools, to save space, and instead has other tools indicated for this kind of work.
Good idea, thanks Carlos
(dd_rescue is used by dd_rhelp; don't use it directly; it is possible, but more cumbersome for this purpose)
Yes, I've used ddrescue before manually before, other than syntax it wasn't too different from dd itself, but adding repeat control for the reads will help.
Another tool is clonezilla, using its own boot CD. It is text mode, and very good for cloning disks and partitions, conserving space, and, I believe, expanding the destination space if wanted. However, I have never tried it on a damaged disk.
This disk isn't too far gone. It currently has 34 sectors marked as bad. They can still be read, they just have to be read numerous times. There has only been one sector 'lost' (data loss) that was identified and the data restored. I think I will be able to get at 100% read off the current disk. I'll make friends with dd_rhelp and take a look at clonezilla. - -- David C. Rankin, J.D.,P.E. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlO3QqEACgkQZMpuZ8Cyrcg1EACeI4+o1cgv9evpUruC6RuXHNia usgAnjk4yhwoZvZxk7SfbymvU8LE4Ecp =Pz0/ -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday, 2014-07-04 at 19:11 -0500, David C. Rankin wrote:
On 07/04/2014 05:00 PM, Carlos E. R. wrote:
Another tool is clonezilla, using its own boot CD. It is text mode, and very good for cloning disks and partitions, conserving space, and, I believe, expanding the destination space if wanted. However, I have never tried it on a damaged disk.
This disk isn't too far gone. It currently has 34 sectors marked as bad. They can still be read, they just have to be read numerous times. There has only been one sector 'lost' (data loss) that was identified and the data restored. I think I will be able to get at 100% read off the current disk. I'll make friends with dd_rhelp and take a look at clonezilla.
Just saw a post on the forums, and it seems that clonezilla aborts on finding bad sectors. It then reccomends using the option "--resque", but as I have not seen it myself, I do not really know where to apply it. Even if the damage is very limited, just a single bad sector can make some tools to abort. Even dd with default options (ie, none), will produce a bad copy. If there are several bad sectors, tools can take an awful ammount of time. - -- Cheers, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEUEARECAAYFAlO5PgMACgkQtTMYHG2NR9XTXQCbBXTatwxghu4bfEuSJmacM5Qh QhIAmMP3Rr43RGPoqnIgUHla86gZEsA= =wwa2 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2014-07-04 16:37 (GMT-0500) David C. Rankin composed:
before spending a couple of hours to find out it won't work..
Adding to what Carlos wrote, the clone may not be in a ready to use state when the clone is complete. Anything in bootloader config or fstab dependent on device ID will break with the clone as the only HD in the system. Some initrds made with dracut get married to the hardware, and won't boot normally when original root device ID is not available at boot time. Sometimes getting around this is merely a matter of waiting for a timeout, then accepting the offered device name as a substitute for the missing device ID. Check /etc/dracut.conf for the state of the hostonly setting to see if this is a potential obstacle for your installation. If it is you should unset it and build a new initrd before cloning. Booting with both source and target attached simulaneously after the clone is complete will result in multiple devices with identical UUIDs too, which also you don't want of any devices affecting the boot process. So, before attempting to use the clone to boot from, take the trouble to restore uniqueness to every device that should be unique. e.g. assign new UUIDs to each filesystem at the very least, and match them to whatever pointers to them exist, if any do, in the bootloader menu and in fstab, which needs to be done after the BIOS and the kernel recognize the existence of the "new" devices on the clone, which I do by a reboot of the cloning media without the original source HD attached. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 07/04/2014 05:22 PM, Felix Miata wrote:
Adding to what Carlos wrote, the clone may not be in a ready to use state when the clone is complete. Anything in bootloader config or fstab dependent on device ID will break with the clone as the only HD in the system. Some initrds made with dracut get married to the hardware, and won't boot normally when original root device ID is not available at boot time. Sometimes getting around this is merely a matter of waiting for a timeout, then accepting the offered device name as a substitute for the missing device ID. Check /etc/dracut.conf for the state of the hostonly setting to see if this is a potential obstacle for your installation. If it is you should unset it and build a new initrd before cloning. Booting with both source and target attached simulaneously after the clone is complete will result in multiple devices with identical UUIDs too, which also you don't want of any devices affecting the boot process.
So, before attempting to use the clone to boot from, take the trouble to restore uniqueness to every device that should be unique. e.g. assign new UUIDs to each filesystem at the very least, and match them to whatever pointers to them exist, if any do, in the bootloader menu and in fstab, which needs to be done after the BIOS and the kernel recognize the existence of the "new" devices on the clone, which I do by a reboot of the cloning media without the original source HD attached.
Good catch. I have no /etc/dracut.conf, so I'm good there, but I do have: root=/dev/disk/by-id/ata-WDC_WD6400BEVT-00A0RT0_WD-WX40A9996688-part6 resume=/dev/disk/by-id/ata-WDC_WD6400BEVT-00A0RT0_WD-WX40A9996688-part5 So we will have a bit of editing to do. It looks like grub menu.lst and fstab are the only two issues. This is an older install, so hopefully the image will work. If not, we can remake that as well. Let me know if you think of any others. Thanks. -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday, 2014-07-04 at 18:22 -0400, Felix Miata wrote:
So, before attempting to use the clone to boot from, take the trouble to restore uniqueness to every device that should be unique. e.g. assign new UUIDs to each filesystem at the very least, and match them to whatever pointers to them exist, if any do, in the bootloader menu and in fstab, which needs to be done after the BIOS and the kernel recognize the existence of the "new" devices on the clone, which I do by a reboot of the cloning media without the original source HD attached.
Yes, that's true. In my case, it is the labels which I have to change, as I mount by label, not uuid. So you have to change them and adapt fstab, and typically also grub. - -- Cheers, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlO5PyYACgkQtTMYHG2NR9V+pgCdExBBps1ivuEFoQWXYQR1vxEJ aEwAoI1yajI1UJQSrivGLuTZhBzN9IxC =aQ+G -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 07/04/2014 11:37 PM, David C. Rankin wrote:
can anyone suggest any further optimizations for the dd clone beyond:
dd if=/dev/sda of=/dev/sdb bs=4096 conv=notrunc,noerror,sync
iflag=fullblock next coreutils version will include an example in the docs: http://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=df5e69705f66e4fc6b... Have a nice day, Berny -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2014-07-04 16:37 (GMT-0500) David C. Rankin composed:
I have had a few bad blocks show up on my laptop hard-drive. I have a new drive (larger) and I would like to duplicate/clone my entire drive
If the old predates 4k sectors internally while the new is as most from the past 3 years with 4k internally, you probably should not to create a new clone, but instead configure the new normally, format the filesystems, and use then rsync or copy from old to new. Performance could noticeably suffer if you do a true clone from a 512 byte to a 4k sector HD. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 07/04/2014 06:02 PM, Felix Miata wrote:
If the old predates 4k sectors internally while the new is as most from the past 3 years with 4k internally, you probably should not to create a new clone, but instead configure the new normally, format the filesystems, and use then rsync or copy from old to new. Performance could noticeably suffer if you do a true clone from a 512 byte to a 4k sector HD.
Hmm..., I knew there was going to be a fly in this ointment somewhere. The old is indeed 512: lsblk -o NAME,PHY-SeC NAME PHY-SEC sda 512 ├─sda1 512 ├─sda2 512 ├─sda3 512 ├─sda5 512 ├─sda6 512 └─sda7 512 sr0 512 So the disk internal sector size will prevent cloning of any old drive for use on a new drive?? Damn, I've got more reading to do. Surely some of the tools take this into account. Bummer -- I really, really didn't want to spend 3 days tweaking a new install. Thank you for catching this. Who knows how much fun I would have gotten myself into otherwise. (Moral -- it is always wise to look before you leap... Wish I would have remembered the wisdom before updating to ios7...) -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 07/04/2014 07:30 PM, David C. Rankin wrote:
So the disk internal sector size will prevent cloning of any old drive for use on a new drive?? Damn, I've got more reading to do. Surely some of the tools take this into account. Bummer -- I really, really didn't want to spend 3 days tweaking a new install.
What about using ibs=512 obs=4096? Will that cause the desired 512 read and 4096 write, or will there be alignment issues attempting to copy from 512 and write 4096? And as Berny suggested could iflags or oflags set to fullblock help? I'll do additional reading and drop a note back, but if anyone knows or has a link, feel free to share :) -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Fri, Jul 4, 2014 at 8:43 PM, David C. Rankin
On 07/04/2014 07:30 PM, David C. Rankin wrote:
So the disk internal sector size will prevent cloning of any old drive for use on a new drive?? Damn, I've got more reading to do. Surely some of the tools take this into account. Bummer -- I really, really didn't want to spend 3 days tweaking a new install.
What about using ibs=512 obs=4096? Will that cause the desired 512 read and 4096 write, or will there be alignment issues attempting to copy from 512 and write 4096? And as Berny suggested could iflags or oflags set to fullblock help?
I just ran across this post again. No, using ibs / obs with dd will not help the long term efficiency of the partitions / filesystems at all. The issue is purely alignment between the physical sectors and the filesystems blocks. File systems are written to optimize performance based on the assumption that a block write is a single atomic operation by the drive. If the alignment is off, the drive has to implement a read / modify / write cycle instead. Since that cycle involves a rotation of the platter, it is extremely inefficient. fyi: Raid 5 and 6 have the same issue, but the most efficient write size is the size of a full raid stripe. XFS as an example will try to structure it's writes to be full stripes when working with Raid. Thus a full stripe write becomes: write all data and parity chunks. A partial stripe write becomes: - read data about to be overwritten, - read old parity info. - Calculate new parity info. - - Write new data, - write new parity info Thus a single partial stripe write to a raid 5 requires at least 4 i/o operations. For a raid 6, it is a minimum of 5 i/o's. Having the filesystem invoke properly aligned full stripe writes is significantly more efficient. Greg Greg -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2014-07-09 20:00, Greg Freemyer wrote:
fyi: Raid 5 and 6 have the same issue, but the most efficient write size is the size of a full raid stripe. XFS as an example will try to structure it's writes to be full stripes when working with Raid. Thus a full stripe write becomes: write all data and parity chunks.
A partial stripe write becomes:
- read data about to be overwritten, - read old parity info. - Calculate new parity info. - - Write new data, - write new parity info
Thus a single partial stripe write to a raid 5 requires at least 4 i/o operations. For a raid 6, it is a minimum of 5 i/o's. Having the filesystem invoke properly aligned full stripe writes is significantly more efficient.
Doh! So that's why! And you mean that number of i/o per disk on the raid? No, that can not be. It has to be one read per disk, that is, 3 reads (which should happen simultaneously). Calculate parity. Do 3 writes, one per disk (which should also happen simultaneously). Mmm... it does not match what you say, so I must be getting it wrong :-? -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 07/09/2014 08:00 PM, Greg Freemyer wrote:
On Fri, Jul 4, 2014 at 8:43 PM, David C. Rankin
What about using ibs=512 obs=4096? Will that cause the desired 512 read and 4096 write, or will there be alignment issues attempting to copy from 512 and write 4096? And as Berny suggested could iflags or oflags set to fullblock help?
I just ran across this post again. No, using ibs / obs with dd will not help the long term efficiency of the partitions / filesystems at all.
When copying partitions or whole disks, I usually use larger buffers like bs=128M or bs=1G. The problem arises if one of the physical input blocks is corrupt, then the whole output block might be padded with Zeros. That's why ddrescue (or dd_rescue) are more specialized in such a failing disk case: they copy with adaptive block sizes, trying to rescue as much data as possible around the failing blocks. For healthy disks, dd(1) perfectly fits my needs though. Have a nice day, Berny -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 09/07/2014 21:55, Bernhard Voelker a écrit :
When copying partitions or whole disks, I usually use larger buffers like bs=128M or bs=1G. The problem arises if one of the physical input blocks is corrupt, then the whole output block might be padded with Zeros.
and without notice :-(
That's why ddrescue (or dd_rescue) are more specialized in such a failing disk case: they copy with adaptive block sizes, trying to rescue as much data as possible around the failing blocks. For healthy disks, dd(1) perfectly fits my needs though.
but who know if a disk is healthy sector copy is only good for cloning, that is duplicating indentical disks in a number jdd -- http://www.dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 07/09/2014 10:18 PM, jdd wrote:
Le 09/07/2014 21:55, Bernhard Voelker a écrit :
When copying partitions or whole disks, I usually use larger buffers like bs=128M or bs=1G. The problem arises if one of the physical input blocks is corrupt, then the whole output block might be padded with Zeros.
and without notice :-(
Huh? POSIX says for conv=noerror: [0] http://pubs.opengroup.org/onlinepubs/9699919799/utilities/dd.html Do not stop processing on an input error. When an input error occurs, a diagnostic message shall be written on standard error, followed by the current input and output block counts in the same format as used at completion (see the STDERR section). If the sync conversion is specified, the missing input shall be replaced with null bytes and processed normally; otherwise, the input block shall be omitted from the output. And dd(1) follows this closely. Have a nice day, Berny -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 07/04/2014 07:43 PM, David C. Rankin wrote:
On 07/04/2014 07:30 PM, David C. Rankin wrote:
So the disk internal sector size will prevent cloning of any old drive for use on a new drive?? Damn, I've got more reading to do. Surely some of the tools take this into account. Bummer -- I really, really didn't want to spend 3 days tweaking a new install.
What about using ibs=512 obs=4096? Will that cause the desired 512 read and 4096 write, or will there be alignment issues attempting to copy from 512 and write 4096? And as Berny suggested could iflags or oflags set to fullblock help?
I'll do additional reading and drop a note back, but if anyone knows or has a link, feel free to share :)
After the 512/4096 sector size mismatch, I looked a bit more for a clone/dd solution - no were found, so I just bit the bullet and installed 13.1 from the NetInstall iso. Jesus there were package problems, mdsum failures, packages listed as installed, but not installed, etc.. But after 8 hours, I think I have a working system to build on. Rather than clone, I am now going though the painful process of copying all files from old disk to new via usblink with my old drive (old drive laying on table powered up with a sata power source and sata-to-usb cable) the disk is just churning away on the last of the TDE build files. The dumbest thing I've ever seen is the desktop choice. I can choose lxde, icewm, WindowMaker, XFCE, Gnome and KDE4, but there is NO choice for KDE3. That makes no sense. As long as Ilya maintains it, if we are going to offer WindowMaker, then we damn sure ought to offer kde3. If it is no longer maintained by Ilya, then dump it, BUT that is not the case and has NOT been the case since 11.4. Somebody, Marcus, etc.. should add it as a install choice so long as it exists maintained at opensuse it is there as a user choice. In addition, we should be able to add any repo prior to install, not just , update, non-oss, etc.. The option to select 'other media' should allow any remote 13.1 repo to be addeded. that would help greatly. Aside from the md5sum issues and the packages I had to install twice, the install was a typical opensuse install. All options set had to be unchecked and all options unset had to be set just to get system mail delivered, create a traditional root account, and disable autologon. The network manager wifi config on install is NOT carried through to lxde desktop. After unplugging enp17s0 (eth0), network manager knew nothing about wlp23s0 despite the installer asking for the essid and taking the wpa_psk password from me during install. (I chocked that one up to growing pains). LXDE is slow, slow compared to icewm or fluxbox. I don't know why, but it is only marginally responsive. I'll finish the install and copy, then I reset the DM and see how the other desktops compare. Thanks for your help with the dd/clone issue. This install will be painful, but at least there will be no 512 sector alignment slowdowns. -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2014-07-13 12:07, David C. Rankin wrote:
LXDE is slow, slow compared to icewm or fluxbox. I don't know why, but it is only marginally responsive.
I have LXDE on an old machine here, and it is certainly not slow.
I'll finish the install and copy, then I reset the DM and see how the other desktops compare. Thanks for your help with the dd/clone issue. This install will be painful, but at least there will be no 512 sector alignment slowdowns.
There was no need to install new, if you did not want to do it. Just create suitable partitions, and copy over the files, using rsync, for instance. Then adjust fstab and grub entries, and install grub1/2 - that's all. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 2014-07-04 19:30 (GMT-0500) David C. Rankin composed:
So the disk internal sector size will prevent cloning of any old drive for use on a new drive??
That's not what I wrote. You can do it, but there will be a performance hit as compared to installing to partitions aligned to the native sector size. I have no idea of the size of the performance hit, but it may be that a new disk degraded may be not be materially different from the native performance of the older HD, or the laptop's disk controller. I simply do not know anything about what the hit can amount to.
Damn, I've got more reading to do. Surely some of the tools take this into account. Bummer -- I really, really didn't want to spend 3 days tweaking a new install.
You do not need a new install, just a less convenient procedure than dd of migrating from old HD to new HD using rsync and/or cp after routine partition and filesystem creation processes, followed up with bootloader installation. Maybe Clonezilla or something else already has easy already worked out as you suggest something should have?
Thank you for catching this. Who knows how much fun I would have gotten myself into otherwise.
I do a lot of cloning, but I've not tried any with/without comparisons to see what the performance penalty might amount to. Somewhere on the web surely someone must have described it by now with 3+ years of 4k sector life behind us. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday, 2014-07-04 at 21:23 -0400, Felix Miata wrote:
On 2014-07-04 19:30 (GMT-0500) David C. Rankin composed:
So the disk internal sector size will prevent cloning of any old drive for use on a new drive??
That's not what I wrote. You can do it, but there will be a performance hit as compared to installing to partitions aligned to the native sector size. I have no idea of the size of the performance hit, but it may be that a new disk degraded may be not be materially different from the native performance of the older HD, or the laptop's disk controller. I simply do not know anything about what the hit can amount to.
There have been reports here on the list: awful perfomance.
Damn, I've got more reading to do. Surely some of the tools take this into account. Bummer -- I really, really didn't want to spend 3 days tweaking a new install.
You do not need a new install, just a less convenient procedure than dd of migrating from old HD to new HD using rsync and/or cp after routine partition and filesystem creation processes, followed up with bootloader installation.
Yes, that's what I did myself recently I migrated to a much larger disk, so I took the chance to enlarge some partitions, add new ones (altering the mount tree), and changing some filesystems types. For instance, you may have originally: / ext3 /home reiser and now you may want: / ext4 /home reiser /usr/share xfs So just format the destination drive, with gparted, for instance (which knows about the new alignment requirements), mount the destination under /mnt, for instance, or /dest, and just rsync source to destination... it doesn't matter if the destination is a dozen partitions and the opriginal just two. That's very easy to do. It is only grub which needs reinstalling, after editing both grub and fstab.
Maybe Clonezilla or something else already has easy already worked out as you suggest something should have?
Maybe. But I'm unsure, it appears to clone the partition layout. Better have a look at their website faq.
Thank you for catching this. Who knows how much fun I would have gotten myself into otherwise.
I do a lot of cloning, but I've not tried any with/without comparisons to see what the performance penalty might amount to. Somewhere on the web surely someone must have described it by now with 3+ years of 4k sector life behind us.
I had simply forgotten about the 500-4000 issue. There are so many details one can forget. :-} - -- Cheers, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlO5QjYACgkQtTMYHG2NR9UP3ACgiZULCAJ83WETlBdxWxvyyo2p od0AoI1s/4P7iN3VewGx1LS04MP4VeWC =J5SK -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On July 4, 2014 8:30:45 PM EDT, "David C. Rankin"
If the old predates 4k sectors internally while the new is as most from the past 3 years with 4k internally, you probably should not to create a new clone, but instead configure the new normally, format the filesystems, and use
On 07/04/2014 06:02 PM, Felix Miata wrote: then rsync
or copy from old to new. Performance could noticeably suffer if you do a true clone from a 512 byte to a 4k sector HD.
Hmm...,
I knew there was going to be a fly in this ointment somewhere. The old is indeed 512:
lsblk -o NAME,PHY-SeC NAME PHY-SEC sda 512 ├─sda1 512 ├─sda2 512 ├─sda3 512 ├─sda5 512 ├─sda6 512 └─sda7 512 sr0 512
None of that matters. What matters is the partition start sectors. With 512 byte sectors on modern disks it doesn't matter at all where the partitions start. With 4kb.sectors, it is important that the partitions start on 4kb boundaries. Greg -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday, 2014-07-05 at 23:25 -0400, Greg Freemyer wrote:
None of that matters.
What matters is the partition start sectors.
With 512 byte sectors on modern disks it doesn't matter at all where the partitions start.
With 4kb.sectors, it is important that the partitions start on 4kb boundaries.
I suppose that what really matters is that the filesystem allocation units match the hard disk "hardware" sectors, so that when the system wants to read or write a filesystem sector, it does not have to translate to accessing two hard disk real sectors. Possibly, if the filesystem indexes 512 byte units, it does not matter? But if it uses, say, 1024 units, half may be on end of a 4K HD sector, and the other half on the start of the next 4K sector. And this also means that it would be better if the filesystem is also using 4 KB sectors itself, right? - -- Cheers, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlO5Q4cACgkQtTMYHG2NR9Ug3ACdH5vhcXn0YQzFDLsL1pnAilCE hPEAni4uGIf+Gs1Fzaywt/RDxyQh/nDI =nk9t -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On July 6, 2014 8:39:35 AM EDT, "Carlos E. R."
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Saturday, 2014-07-05 at 23:25 -0400, Greg Freemyer wrote:
None of that matters.
What matters is the partition start sectors.
With 512 byte sectors on modern disks it doesn't matter at all where the partitions start.
With 4kb.sectors, it is important that the partitions start on 4kb boundaries.
I suppose that what really matters is that the filesystem allocation units match the hard disk "hardware" sectors, so that when the system wants to read or write a filesystem sector, it does not have to translate to accessing two hard disk real sectors.
Possibly, if the filesystem indexes 512 byte units, it does not matter?
I don't know of a Linux filesystem that supports 512 byte blocks, but I'm sure they exist. Note that anything less than 4K blocks on a 4K sector drive is going to cause bad performance. The reason has to do when a one block write is performed. If the block is a multiple of the sector size (1x, 2x, 3x, 4x, etc) then the drive can simply write the new data to the sectors. If the block is half the size of a sector, then a one block write by the filesystem becomes a read/modify/write cycle by the drive firmware. A 5200 rpm drive takes about 10 msecs to go around, so that adds 10 msecs to that one page write. It is a huge performance killer. The goal is to have a filesystem write to the drive not require any reads from the drive.
But if it uses, say, 1024 units, half may be on end of a 4K HD sector, and the other half on the start of the next 4K sector.
Yes, now think about a write to that split sector. Both sectors have to be read, modified, written. Again a 10 msec delay.
And this also means that it would be better if the filesystem is also using 4 KB sectors itself, right?
Filesystems call them pages or blocks, but yes. Or a multiple. Ie. 4K, 8K, 12K, etc. And the logical blocks need to align with the physical sectors so a filesystem write becomes exclusively a disk write. Fyi: most Linux filesystems use a 4K page by default Fyi2: Linux partitioning tools started defaulting to 1MiB partition alignment a few years ago. Windows mad that same transition with Vista or Win7. If your first partition starts at sector 2048 you have 1MiB alignment.
- -- Cheers, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Greg -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday, 2014-07-06 at 09:50 -0400, Greg Freemyer wrote:
On July 6, 2014 8:39:35 AM EDT, "Carlos E. R." <> wrote:
Possibly, if the filesystem indexes 512 byte units, it does not matter?
I don't know of a Linux filesystem that supports 512 byte blocks, but I'm sure they exist.
vfat does - but it is not a native Linux filesystem. Ext2... 1 K. I thought it allowed 0.5 K.
Note that anything less than 4K blocks on a 4K sector drive is going to cause bad performance.
Of course. Unless you need a small size for a partition dedicated to nntp or maildir storage, with tons of very small files. I recall an specific filesystem creation option for nntp partition somewhere. Yast? mkfs? But based on what you explain below, about a small write causing a read-write double cycle, it can't be done.
The reason has to do when a one block write is performed. If the block is a multiple of the sector size (1x, 2x, 3x, 4x, etc) then the drive can simply write the new data to the sectors.
If the block is half the size of a sector, then a one block write by the filesystem becomes a read/modify/write cycle by the drive firmware. A 5200 rpm drive takes about 10 msecs to go around, so that adds 10 msecs to that one page write. It is a huge performance killer.
Yes, that is.
The goal is to have a filesystem write to the drive not require any reads from the drive.
Right.
But if it uses, say, 1024 units, half may be on end of a 4K HD sector, and the other half on the start of the next 4K sector.
Yes, now think about a write to that split sector. Both sectors have to be read, modified, written. Again a 10 msec delay.
A lot.
And this also means that it would be better if the filesystem is also using 4 KB sectors itself, right?
Filesystems call them pages or blocks, but yes.
Yes, I always forget the correct nomenclature. O:-)
Or a multiple. Ie. 4K, 8K, 12K, etc.
And the logical blocks need to align with the physical sectors so a filesystem write becomes exclusively a disk write.
Yep.
Fyi: most Linux filesystems use a 4K page by default
Fyi2: Linux partitioning tools started defaulting to 1MiB partition alignment a few years ago. Windows mad that same transition with Vista or Win7. If your first partition starts at sector 2048 you have 1MiB alignment.
I have seen some tools, this year, that do not. - -- Cheers, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlO5XZwACgkQtTMYHG2NR9VkdQCeK++71X1dmF0dS3u8aaf/uYYq +dYAnjwyXLkppJ33ftfhdvrb9467NvFm =q/iy -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2014-07-06 16:30 (GMT+0200) Carlos E. R. composed:
On Sunday, 2014-07-06 at 09:50 -0400, Greg Freemyer wrote:
"Carlos E. R." <> wrote:
Possibly, if the filesystem indexes 512 byte units, it does not matter?
I don't know of a Linux filesystem that supports 512 byte blocks, but I'm sure they exist.
vfat does - but it is not a native Linux filesystem. Ext2... 1 K. I thought it allowed 0.5 K.
DOS refers to blocksize as cluster size. No FAT filesystem as used by any PC or MS DOS for an IBM PC and compatibles HD ever had a cluster size of less than 4 sectors, 2k bytes. The only FAT16x partitions using that minimum had a size of up to 128M, after which it went to 4k for up to 256M, after which it went to 8k for up to 512M, etc. up to the 2G partition maximum. FAT12 partitions all used a 4k cluster size. IIRC, some floppy types used a cluster size of 2 sectors, meaning only 1 sector at a time was never natively handled on those types. FAT32 minimum cluster size is also 4k under MS DOS 7.1. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Carlos E. R. wrote:
Possibly, if the filesystem indexes 512 byte units, it does not matter? I don't know of a Linux filesystem that supports 512 byte blocks, but I'm sure they exist. vfat does - but it is not a native Linux filesystem. Ext2... 1 K. I thought it allowed 0.5 K.
xfs supports 512B up to "pagesize" (in powers of 2). Of more interest would be the inodes, which are limited to 2k, with the minimum (and default) being 256 bytes. If someone needed "last access" turned on, it might be good to look into using a higher value there. Certainly, this raises the Question of performance w/r/t writes which have to update some bit in the inode on each write to indicate the file has changed. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 07/04/2014 08:30 PM, David C. Rankin wrote:
I knew there was going to be a fly in this ointment somewhere. The old is indeed 512:
lsblk -o NAME,PHY-SeC NAME PHY-SEC sda 512 ├─sda1 512 ├─sda2 512 ├─sda3 512 ├─sda5 512 ├─sda6 512 └─sda7 512 sr0 512
And what about the new? Anybody? I run this on my recent disks and still get 512. -- /"\ \ / ASCII Ribbon Campaign X Against HTML Mail / \ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2014-07-06 01:37 (GMT-0400) Anton Aylward composed:
And what about the new?
If you want maximum possible throughput, don't clone from an old HD with 512 sectors to one that uses 4k, euphemistically called "advanced format" by their manufacturers. Instead, partition with a tool that understands how to optimize advanced format devices, create new filesystem(s), copy the content, install bootloader. It's not that big of a deal if: 1-you're not trying to partition with a naive partitioning tool; or 2-you're not demanding optimal small file performance, in which case treaure your 512 HDs and do whatever you can to make them last.
I run this on my recent disks and still get 512.
It may depend on the age of the tool, and what kind of lie the device firmware is providing if it is lying. If the disk was made after 2010, it almost certainly has 4k sectors if it's any of the major brands that have since existed, WD, Seagate, Toshiba, Hitachi, Fuji, Samsung. Some older already have 4k. Goto the manufacturer's web site with the model number and find out for sure, if you're convinced it matters to your installation(s). The question isn't whether you can ignore 4k boundaries, because it is allowed. The disks internally manage by reading and writing 4k chunks whenever smaller is requested. Different brands have different names for the process, but commonly the term "512 emulation" is used. The relevant question is what the performance penalty to be paid is by not aligning partitions on 4k boundaries, not whether you must or must not adhere to 4k boundaries. http://www.seagate.com/tech-insights/advanced-format-4k-sector-hard-drives-m... has one explanation of the emulation process, among other ramifications of 4k. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday, 2014-07-06 at 03:09 -0400, Felix Miata wrote:
On 2014-07-06 01:37 (GMT-0400) Anton Aylward composed:
I run this on my recent disks and still get 512.
It may depend on the age of the tool, and what kind of lie the device firmware is providing if it is lying. If the disk was made after 2010, it
Several tools give you this info. Fdisk does, but hdparm -I tells way more. /dev/sde: Configuration: Logical max current cylinders 16383 16383 heads 16 16 sectors/track 63 63 -- CHS current addressable sectors: 16514064 LBA user addressable sectors: 268435455 LBA48 user addressable sectors: 3907029168 Logical Sector size: 512 bytes <========= Physical Sector size: 4096 bytes <========= Logical Sector-0 offset: 0 bytes device size with M = 1024*1024: 1907729 MBytes device size with M = 1000*1000: 2000398 MBytes (2000 GB) cache/buffer size = unknown Form Factor: 3.5 inch Nominal Media Rotation Rate: 7200 /dev/sda: Configuration: Logical max current cylinders 16383 16383 heads 16 16 sectors/track 63 63 -- CHS current addressable sectors: 16514064 LBA user addressable sectors: 268435455 LBA48 user addressable sectors: 976773168 Logical/Physical Sector size: 512 bytes <========= device size with M = 1024*1024: 476940 MBytes device size with M = 1000*1000: 500107 MBytes (500 GB) cache/buffer size = 16384 KBytes Nominal Media Rotation Rate: 7200 - -- Cheers, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlO5RVUACgkQtTMYHG2NR9UyTwCfW0LLDmBa9dIUHIyoJeZLRW2C dbcAoJAN+PSDaZDaCNUGLq3tuaVzQKAO =yuQm -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 07/06/2014 08:47 AM, Carlos E. R. wrote:
On Sunday, 2014-07-06 at 03:09 -0400, Felix Miata wrote:
On 2014-07-06 01:37 (GMT-0400) Anton Aylward composed:
I run this on my recent disks and still get 512.
It may depend on the age of the tool, and what kind of lie the device firmware is providing if it is lying. If the disk was made after 2010, it
Several tools give you this info. Fdisk does, but hdparm -I tells way more.
/dev/sde:
Configuration: Logical max current cylinders 16383 16383 heads 16 16 sectors/track 63 63 -- CHS current addressable sectors: 16514064 LBA user addressable sectors: 268435455 LBA48 user addressable sectors: 3907029168 Logical Sector size: 512 bytes <========= Physical Sector size: 4096 bytes <========= Logical Sector-0 offset: 0 bytes device size with M = 1024*1024: 1907729 MBytes device size with M = 1000*1000: 2000398 MBytes (2000 GB) cache/buffer size = unknown Form Factor: 3.5 inch Nominal Media Rotation Rate: 7200
Yours is bigger than mine but ... /dev/sda: ATA device, with non-removable media Model Number: WDC WD10EALS-00Z8A0 Serial Number: WD-WCATR4740139 Firmware Revision: 05.01D05 Transport: Serial, SATA 1.0a, SATA II Extensions, SATA Rev 2.5, SATA Rev 2.6 Standards: Supported: 8 7 6 5 Likely used: 8 Configuration: Logical max current cylinders 16383 16383 heads 16 16 sectors/track 63 63 -- CHS current addressable sectors: 16514064 LBA user addressable sectors: 268435455 LBA48 user addressable sectors: 1953525168 Logical/Physical Sector size: 512 bytes <============ device size with M = 1024*1024: 953869 MBytes device size with M = 1000*1000: 1000204 MBytes (1000 GB) No line about separate physical size
/dev/sda:
Configuration: Logical max current cylinders 16383 16383 heads 16 16 sectors/track 63 63 -- CHS current addressable sectors: 16514064 LBA user addressable sectors: 268435455 LBA48 user addressable sectors: 976773168 Logical/Physical Sector size: 512 bytes <========= device size with M = 1024*1024: 476940 MBytes device size with M = 1000*1000: 500107 MBytes (500 GB) cache/buffer size = 16384 KBytes Nominal Media Rotation Rate: 7200
-- Cheers, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
-- /"\ \ / ASCII Ribbon Campaign X Against HTML Mail / \ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2014-07-06 11:25 (GMT-0400) Anton Aylward composed:
Carlos E. R. wrote: ...
LBA48 user addressable sectors: 3907029168 Logical Sector size: 512 bytes <========= Physical Sector size: 4096 bytes <=========
... Yours is bigger than mine but ...
/dev/sda:
ATA device, with non-removable media Model Number: WDC WD10EALS-00Z8A0 ... LBA48 user addressable sectors: 1953525168 Logical/Physical Sector size: 512 bytes <============
No line about separate physical size
I did some investigating after seeing your question. If you want to see separate lines reported for logical and physical, all you can do is get a different HD, and cross your fingers if it isn't less than 2 years old: Brand Model Made HDPVer RPM LogSz PhysSz Log/Phys Addressable MB Size MiB Size WD WD5000LPVX 201405 9.43 5400 512 4096 976,773,168 500.11 476.94 Tosh DT01ACA100 201312 9.43 7200 512 4096 1,953,525,168 1000.20 953.87 Seag ST1000DM003 201310 9.43 7200 512 4096 1,953,525,168 1000.20 953.87 Seag ST2000DM001 201307 9.43 7200 512 4096 3,907,029,168 2000.40 1907.73 Seag ST2000DM001 201302 9.43 7200 512 4096 3,907,029,168 2000.40 1907.73 WD WD20EURS 201207 9.43 NA 512 4096 3,907,029,168 2000.40 1907.73 WD WD10EADS 201205 9.43 NA 512 1,953,525,168 1000.20 953.87 WD WD10EADS 201205 9.39 NA 512 1,953,525,168 1000.20 953.87 WD WD10EADS 201205 9.37 NA 512 1,953,525,168 1000.20 953.87 Seag ST2000DL003 201107 9.43 5900 512 3,907,029,168 2000.40 1907.73 Seag ST1000DL002 201106 9.43 5900 512 1,953,525,168 1000.20 953.87 Sams HD155UI 201012 9.43 5400 512 512 2,930,277,168 1500.30 1430.80 Seag ST31500341AS 201011 9.43 7200 512 2,930,277,168 1500.30 1430.80 Seag ST3500418AS 201011 9.43 7200 512 976,773,168 500.11 476.94 Seag ST3200542AS 201005 9.43 5900 512 3,907,029,168 2000.40 1907.73 Seag ST3200542AS 201005 9.39 5900 512 3,907,029,168 2000.40 1907.73 Seag ST3200542AS 201005 9.37 5900 512 3,907,029,168 2000.40 1907.73 Seag ST3160215ACE 200912 9.43 NA 512 512 312,581,808 160.04 152.63 Seag ST3320613AS 200811 9.43 7200 512 625,142,448 320.07 305.25 Seag ST3250620A 200811 9.43 NA 512 512 488,397,168 250.06 238.48 Seag ST3250620A 200811 9.39 NA 512 512 488,397,168 250.06 238.48 Seag ST3250620A 200811 9.37 NA 512 512 488,397,168 250.06 238.48 Seag ST3320613AS 200808 9.43 7200 512 625,142,448 320.07 305.25 Seag ST3320620AS 200801 9.43 NA 512 512 625,142,448 320.07 305.25 Seag ST3500630NS 200709 9.43 NA 512 512 976,773,168 500.11 476.94 Seag ST3500630NS 200702 9.43 NA 512 512 976,773,168 500.11 476.94 HitachHDS725050KLA3200702 9.43 NA 512 976,773,168 500.11 476.94 Seag ST3250620A 200606 9.37 NA 512 512 488,397,168 250.06 238.48 WD WD800JD75MSA1200601 9.43 NA 512 156,250,000 80.00 76.29 HitachHDS722580VLSA200501 9.43 NA 512 160,836,480 82.35 78.53 WD WD1200BB00DAA200302 9.43 NA 512 234,375,000 120.00 114.44 -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2014-07-07 04:40, Felix Miata wrote:
On 2014-07-06 11:25 (GMT-0400) Anton Aylward composed:
No line about separate physical size
I did some investigating after seeing your question. If you want to see separate lines reported for logical and physical, all you can do is get a different HD, and cross your fingers if it isn't less than 2 years old:
That's quite a table, thanks :-)
Brand Model Made HDPVer RPM LogSz PhysSz Log/Phys Addressable MB Size MiB Size
-- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
First off -- I didn't have time to read all the replies. I started to read them, but the 1st reply was a copy of your note (maybe there was something appended to the end, I dunno, TLDLook). If your current drive is still working, why not copy from your currently booted system? Else, yes -- most rescue setups should support the copy (unless new is USB3, then depends on rescue version & what it contains). 2. Don't do that! You will be copying a fragmented file system onto a new drive. Ick! Create the new drive with ideal settings for the new drive. Then use whatever util your filesystem has for doing a full backup and restore. I.e. -- xfs_dump/restore -- will dump and restore all extended file attributes, permissions devices, hard links. Many utils like tar, won't. I only mention the xfs util, as I know it does dump and restore everything... 2.a -- is there a need to do "dd" to the 1st disk? I.e... seems like it might be prudent to do a dump/restore from your HD to the USB disk as well. 2.b -- I use this disk copy script to copy disks (for xfs.. for other file systems, sub in that file system's full dump & restore util (or find a general dump/restore that handles ACL's xattr's, set-capability-bits (different from SETUID/SETGID)... etc for your file system). Script:
more xfscopy #dated 2011-feb-6 #!/bin/bash -ue # $1=source # $2=target
# -b # = blocksize # -l # = level (0=all) # -J = inhibit inventory update # -p # = progress report every # seconds # next to last arg is '-' for stdout/in & out # last arg is for source or destination mount points mbuffer_size=1024M xfs_bs=128k xfs_report_interval=300 # prios c:1=real(don't use), 2=best-effort(timeshare); 3=idle # in Best effort, -n=0-7 where 0=highest, 7=lowest, but not strict! # dump_cprio=-19 restore_cprio=-10 dump_dprio="-c3" restore_dprio="-c 2 -n3" nice=/usr/bin/nice ionice=/usr/bin/ionice $nice $dump_cprio $ionice $dump_dprio \ xfsdump -b $xfs_bs -l 0 -p $xfs_report_interval -J - "$1" | \ $nice -5 mbuffer -m $mbuffer_size -L | \ $nice $restore_cprio $ionice $restore_dprio \ xfsrestore -b $xfs_bs -B -F -J - "$2" -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2014-07-09 23:45, Linda Walsh wrote:
I.e. -- xfs_dump/restore -- will dump and restore all extended file attributes, permissions devices, hard links. Many utils like tar, won't.
Of course tar does. It is ACLs which may not. File attributes, permissions, links, are not extended attributes, they are normal. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Carlos E. R. wrote:
On 2014-07-09 23:45, Linda Walsh wrote:
I.e. -- xfs_dump/restore -- will dump and restore _all_ extended file attributes, permissions, devices, hard links. Many utils like tar, won't.
Of course tar does. It is ACLs which may not.
--- Um... did you miss the word "_all_"?? Most backup/restore utils don't handle file capabilities, ACL's or extended attributes used as alternate data forks (like those used by Samba, recently). This includes tar. The common linux info stored in the inode is restored by tar -- I agree. But my statement was about something that did all of them. tar does handle all of them (yet).
File attributes, permissions, links, are not extended attributes, they are normal.
"normal"? as in existing on FAT32, initfs(ramdisks) or CD-ROM's? *poke*... :-) Me question normal? nahhhh -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2014-07-10 01:58, Linda Walsh wrote:
Carlos E. R. wrote:
On 2014-07-09 23:45, Linda Walsh wrote:
I.e. -- xfs_dump/restore -- will dump and restore _all_ extended file attributes, permissions, devices, hard links. Many utils like tar, won't.
Of course tar does. It is ACLs which may not.
--- Um... did you miss the word "_all_"??
You said "all extended" :-) File attributes are not "extended attributes". Nor are permissions, etc. ACLs are extended, but you did not name "ACLs" in your list ;-) I'm trying to point out that your choice of words was confusing, because file attributes, permissions, links, are stored on tar archives (a device file is just a file with an attribute saying so).
File attributes, permissions, links, are not extended attributes, they are normal.
"normal"? as in existing on FAT32, initfs(ramdisks) or CD-ROM's? *poke*... :-)
Normal Linux permissions and attributes. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
participants (9)
-
Anton Aylward -
Bernhard Voelker -
Carlos E. R. -
David C. Rankin -
Felix Miata -
Greg Freemyer -
jdd -
ka1ifq -
Linda Walsh