From: robin_listas@es.invalid
On 2025-05-13 20:45, Paul wrote:
> On Mon, 5/12/2025 8:43 PM, Carlos E.R. wrote:
>> On 2025-05-13 00:22, CtrlAltDel wrote:
>>> On Fri, 9 May 2025 17:59:41 -0000 (UTC), evanmac wrote:
>>>
>>>> con fecha5 May 2025 y hora 11:21:46 GMT+1, "CtrlAltDel"
>>>> sacó de su cabeza:
>>>>
>>>>> if there are any apps I can use to convert them to SSD's?
>>>>
>>>> app is *SOFTware*, while HDD/SSD are *HARDware*
>>>>
>>>> Beyond that, you'd like to "convert" a fish into a bird (via software),
>>>> seems it possible to you?
>>>
>>> Well, I'm using Linux Mint 22.1 if that helps any. I know you probably
>>> couldn't do anything like this on Windows but, I am using Linux.
>>>
>>> I mean, I already have these HDD's, why not re-purpose them and give them
>>> another function as SSD's. I've been researching it and they say solid
>>> state drives give you faster boot times, less power consumption, faster
>>> read/write speeds, etc...
>>>
>>> Why in the world wouldn't I want to take what I have and upgrade them into
>>> more powerful and useful drives? I know how to solder and if I need to
>>> buy a few parts, as long as they are very inexpensive, I can do that.
>>
>> What the fuck are you talking about?
>>
>> We told you, it is impossible to convert a hard disk into an SSD, or the
reverse.
>>
>
> It could be a terminology issue.
>
> You can *clone* a slow HDD onto a faster SSD. This is
> not exactly the best way to do it, and is merely an
> illustration of doing it in the old days. This would cause
> excess wear on the destination SSD (writing 512 byte chunks
> to 64K pages would be stupid). However, the Linux System Write cache
> is going to change the transaction size at some point, so this
> is not as bad as a superficial analysis would indicate.
>
> sudo dd /dev/sda /dev/sdb # Works well if the disks are exactly the
same size.
> # We actually have some SSDs that are
exactly
> the same size to the byte. as 1TB HDDs.
I would specify "bs=16M" (or any other sensible figure). From
experiments, much faster.
On some machines, there is the side effect that the kernel buffers fill
up with this activity, and the rest of the processes are starved.
Specially noticed when writing several isos to several USB (slow)
sticks. Use then "oflag=direct".
>
> You can't convert motors and heads into NAND flash chips,
> so you cannot exactly convert between hardware type.
> This is not exactly a "Tea, Earl Gray, Hot" machine :-)
>
> By cloning an older disk, you can move the contents
> from one place to another.
Yes, but the logical sector size must be the same. I can explain this
with FAT: it is a table of sectors. Files are allocated several sectors
in that table. The size of sectors must be the same, or the allocation
doesn't match in the destination.
>
> *******
>
> As an experiment, I took my Lexar NS100 256GB SSD and tried to move
> it to my WD Blue 250GB HDD. This was just a test to see how
> easy it is for a Year Of The Linux Desktop user, to move from one
> disk to another.
>
> 1) Clonezilla
>
> It warned that it does not handle destination disks which are smaller
than the source.
> while I did not test it, there is no reason to believe they could handle
the
> other case. (If you move a GPT partitioned disk to a larger disk, you
have to relocate
> the GPT table to the correct offset, and not all softwares do this
correctly. There are
> yet other softwares that detect this error, and they will put up a
warning dialog.)
>
> Clonezilla still offered to carry on, even though the partition would
not fit, and
> a second error dialog appeared when the transfer failed ("no space").
>
> Conclusion: Not ready for prime time. This kind of behavior causes user
hair loss.
So the professionals can make a profit ;-)
>
> 2) Gparted
>
> Now, I like Gparted. You can (almost) always get a result with it.
> Only once did it trip in a spectacular fashion and drop all its drinks
on the floor.
>
> sudo gparted
For example, you write a partition table from scratch. You assign the
partitions. Nothing written yet to disk. You decide to make one
partition bigger or smaller: it does not allow you to do it. You have to
delete that partition and all partitions behind it, which is ridiculous.
>
> OK, so to start with, I thoroughly erased the destination disk. That's
> for the purposes of doing experiments, I don't want to pollute the
> results via the "history" of the disk drive.
>
> The first step, is getting GParted to prepare the device for GPT
partitioning.
> This might be termed as "Initialize" or "Disk Initialize", and you have to
> select MSDOS or GPT, to match the partition scheme used on the source disk.
And this operation has to be committed before continuing.
>
> Next, in Gparted, the menu has "Copy" and "Paste". This is how we clone!
>
> You can highlight a partition on /dev/sda, select "Copy", then change
> the disk selector to the blank-GPT /dev/sdb and press "Paste".
Ah! I never tried this.
It copies the contents? Or only the definitions of the partitions?
>
> When the destination drive is too small, or, there is no available space
> big enough for a too-large partition, the Paste menu item is greyed out.
> This means you need to do a "shrink" on the source partition, before
> a Copy/Paste to the second smaller disk drive will work. Fair enough.
It should allow to do this on the fly. Does clonezilla do it?
>
> GParted will not do an on-the-fly resize like some commercial
> softwares offer. That's fine. Breaking the operation into two atomic steps,
> is all part of the "component nature" of Partition Management. Utilities
> do not act greedy with the convenience functions. They strive for accuracy
> and "no damage to user goods". That's the way it should be.
>
> So I got my materials onto the destination.
>
...
--
Cheers, Carlos.
--- SoupGate-DOS v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
