Linux is my main system, but I prefer using NTFS for various use cases and in fact some use cases require something like NTFS.
The ST400 is the successor of several Zalman-rebranded iODD devices which bring a similar feature set. The main selling point: store your ISO files, VHDs and what not on an NTFS, FAT32 or exFAT drive and mount them in a way that makes the drive enclosure pose as an optical drive (CD/DVD …).
I had so far used the older Zalman-branded and iODD-branded drive enclosures with up to 2 TB hard drives and SSDs. I also have an iODD mini with 512 GB and now wanted to upgrade the ST400 from a 2 TB SSD to 4 TB.
So the first thing I did was generate the two partitions I wanted on the drive, then copy the data over from the old one using rsync. Nothing spectacular here.
Then, after moving the new bigger SSD into the ST400 enclosure, the enclosure would report “No supported partition” with the 2.74.4 firmware. Dang.
Well, so I thought this could be remedied by converting to GPT from MBR. After all the size is known to create boot problems, because of start sectors being beyond the addressable range. Alas, I don’t want to boot from the drive itself (in its function as HDD/SSD). Anyway, gdisk /dev/sdX will basically do the whole job swiftly, if you write (w) the converted GPT it automatically creates from the MBR partition table. I did a backup of the first 2 MiB of the disk using dd in order to recover from a possible botched conversion1. But all went well. A quick partprobe /dev/sdX as superuser made the changes available.
I also had to do some shuffling of the partition sizes, since the iODD ST400 manual states:
At the first time, automatically finds mountable files on the largest partition (GPT / MBR, NTFS / exFAT / FAT32)
… and I needed to accommodate that. The outcome was this:
Number Start (sector) End (sector) Size Code Name 1 2048 4294967295 2.0 TiB 8300 Linux filesystem 2 4294967296 8001509375 1.7 TiB 8300 Linux filesystem
Notice something? For starters of course the device kept complaining about “No supported partition”, but also it says Linux filesystem. What the heck? Well 8300 is Linux, I get that. But why did it pick that in the first place?
Turns out gdisk does that independent of the file system on the actual partition, so I neede gdisk again to switch to type 0700 (Microsoft basic data). And lo and behold that did the trick. After syncing, disconnecting and reconnecting the firmware on the ST400 was able to recognize the larger partition and is able to list the files and folders on it as it did with the 2 TB drive.
So success.
// Oliver
PS: the only issue I had was gparted erroring out on me with a mysterious error. Given the whole resizing process ran for 12 hours or so and I didn’t attend it throughout, it was quite annoying to see an error and no indication of where it failed. Fortunately going by the timestamp the relevant resizing should have been done and looking at the disk confirmed it. After checking the integrity of the partitions, I resized the remaining one and was finally done. Error was:
$ sudo gparted /dev/sdh GParted 1.4.0 configuration --enable-libparted-dmraid --enable-online-resize libparted 3.3 (gpartedbin:55435): glibmm-ERROR **: 20:22:47.643: unhandled exception (type std::exception) in signal handler: what: basic_string::_M_replace_aux Trace/breakpoint trap
- Side-note: this isn’t about backups, this is about speed. Copying huge amounts of data back and forth takes vast amounts of time and wears down the SSD, albeit slowly. [↩]
>the whole resizing process ran for 12 hours
so long? is that normal?
I was just investigating my backup HDD this week, since I ran out of space.
I have 32 GB fat32, 250 GB unallocated, 1.2 TB ext4, 120 GB ext4 encrypted, 180 GB ext4.
I think I could not decide if I wanted to make a ntfs partition in the unallocated space or merge it with the ext4 one, so I just left it there. And the last partition was a full image of my laptop, so I could boot from the external HDD. But I do not really need that.
Would be much more flexible to have an almost 1.8 TB linux partition and the encrypted partition as a file container
But I would hate to have to wait for hours for a repartitioning
Since the partition was pretty full I didn’t mind the lengthy process. It was anyway just via USB and resizing is bound to have other characteristics than mere copying.
If I didn’t make any mistake 1.8 TiB (~2.0 TB) it comes out at 43.7 MiB/s on average. That’s indeed not very spectacular. But keep in mind that I measured the whole operation not just the resizing of that one partition. I think moving and then resizing incurs some extra “cost”.
Either way, I left it running on the side and so didn’t mind the time it took.
Danke sehr. Das hat mir geholfen.
>If I didn’t make any mistake 1.8 TiB (~2.0 TB) it comes out at 43.7 MiB/s on average. That’s indeed not very spectacular.
That would be bad even for USB 2
And mine should be slower than yours since I use a HDD with USB 2 not an SSD
These external disk are annoying. I made a backup last week and it got an filesystem error, which triggered it to remount the drive as read-only.
Then I started the SMART selftest, and it was supposed to run 4 hours, but after 90% completion it got stuck, and I aborted the test after 2 days.
That does not look like a reliable drive.
Now I have just bought a new used drive at an auction. I do not usual buy things, however that one was cheaper than usual because the seller mislabeled it as 2 GB rather than 2 TB.
But it is already at 20694 power on hours, and has 41 errors in its error log. I wonder what the self-test will reveal. I tried already to run one, but it seems to have been canceled when the host put the drive in standby
My old drive is the worst
I started my partition resizing in gparted on Sunday afternoon. It said 17 hours left.
It has been running ever since, and now it is saying 47 hours left. (and there is bug where the details view seems to show it modulo 24)
It keeps getting slower each day, now it is down to 2.23 MB/s
I probably should not have started the resizing, but if I abort it now, I lose my data?
Perhaps I could suspend gparted/e2image to give the drive some rest? but that might abort it
In the middle of this, there was notification the drive might be failing, so I looked at smart and it said
1 Raw_Read_Error_Rate 0x002f 040 040 051 Pre-fail Always FAILING_NOW 120235
3 Spin_Up_Time 0x0027 172 171 021 Pre-fail Always – 4366
4 Start_Stop_Count 0x0032 100 100 000 Old_age Always – 457
5 Reallocated_Sector_Ct 0x0033 200 200 140 Pre-fail Always – 0
7 Seek_Error_Rate 0x002e 200 200 000 Old_age Always – 0
9 Power_On_Hours 0x0032 098 098 000 Old_age Always – 1616
now it says
1 Raw_Read_Error_Rate 0x002f 001 001 051 Pre-fail Always FAILING_NOW 305516
Yikes, this doesn’t sound good at all. I would be just as hesitant as you to stop it, btw. I am no expert, though. If it’s a spinning hard drive, chances are that some data recovery professionals would be able to scrape the data off of it (it’s a lot more affordable, albeit still expensive, these days). Otherwise as long as it physically runs ddrescue is a good help — provided you have enough disk space to write the image to. As I gather from your comments, that’s not the case.
I don’t know what to recommend, to be honest.
On Thursday, I canceled my repartitioning
Last week it had progressed from 76% to 79%, and went down to 1,02 MB / s. But since that was averaged over the entire run, the rate today looked more like 1 block / s, 4KB/s.
At that speed, it would have needed to run 2 more years
But I had to cancel it, because I had to get on a plane flight, and had to replace my laptop battery first because that battery was also failing
But I made a core dump first. Perhaps I can load that and continue it later.
I tried some crazy things. Usually you cannot turn a drive off during repartioning.
But I could suspend the process with gdb, and then turn the drive off. I thought replacing the cable might help (it did not). Then after turning it on again, I had to edit the file descriptors in the process, so it would point to the new device (it also changed from /dev/sda to /dev/sdb)
>I don’t know what to recommend, to be honest.
>I did a backup of the first 2 MiB of the disk using dd in order to recover from a possible botched conversion
you could have suggested to make a backup of more than 2 MB before doing anything to a drive…