Nazo

Ok, so due to my storage problems I have talked with family and someone gave me a NAS drive they weren't using. (It's basically new. Like 40 hours of use.) I have it in a drive bay that can be turned off so I don't have to listen to it spinning (though honestly it's the least annoying mechanical drive I've ever had.) I still want to keep it off when I'm not using it (most of the time,) hoping it will last that much longer.

Besides the obvious unmounting mounted partitions, what's the safest, best way to "remove" a drive in Linux before actually powering it off? I want to be sure all writes (even filesystem stuff) are done and the drive is ready for safe removal, but of course the computer sees a SATA drive as "internal."

No I'm not buying an enclosure.

#Linux #Harddrives #Storage

Feb 28 at 12:38amWeb
Show threadNazoFeb 28

Right now what I'm doing is:

sudo hdparm -Y /dev/[device]
echo 1 | sudo tee /sys/block/[device]/device/delete

Based on some initial searching.

The hdparm -Y issues a "sleep" command and then the "delete" is supposed to remove it from the listing so it won't be polled. I do this manually (from a script for now) but I'd really like something more optimized for device removal (eg ensuring all writes to the device have stopped and etc even before issuing the command.)

Plus it would be super nice if I didn't have to find out which devicename it's using each time. (I have other removable devices after all, so it's not guaranteed to always be the same letter.) Maybe I could do a UUID or something for the disk itself?

Show threadScott VE3QBZFeb 28
@nazokiyoubinbou mounting the drive with the sync option will help - forces all writes to be committed immediately rather than buffered.
Show threadNazoFeb 28
@scott That's a good idea, thanks.
Show threaddsFeb 28

@nazokiyoubinbou mounting with the sync option can have a pretty big impact on performance though, and probably won't achieve much that unmounting (which will wait for the filesystem to sync) doesn't already do, just something to keep in mind if it's behaving abnormally slow.

The other thing to consider here is that the disk itself may have an unwritten cache. I've done something like this previously and had to use the sg_sync command before powering the disk off, i was seeing data loss otherwise, even with a filesystem sync/unmount beforehand. (This might be specific to the type of disk, and blockdev --flushbufs might achieve the same thing but more generally, maybe?)

As to the latter point of getting the name of the disk automatically... if your version of lsblk supports --filter you could do something like lsblk -dno NAME --filter 'ID == "blah"' and use lsblk -o +ID to find the id of your disk (then substitute it for "blah")

Show threadNazoFeb 28

@ds Hmm. I'll have to look into that. It might make the most sense just to have a simple script for the specific device.

I do wish there was something like the program I once had for Windows that made an icon similar to the normal safe remove disk and would list even internal drives. Though, in the end, Windows wasn't meant to do this either and is even less trustworthy at it, so I don't know how well that program worked.

Oh and I'll take the performance impact of synced writes. Reliability is more important and this is mostly just a backups drive. I'm usually going to turn it off when I'm done with it, so knowing when it's actually done matters.

lsblk --filter is working on the distro I'm in atm and I might incorporate that to automate this.

Show threadNazoFeb 28

@ds Alrighty, after a bit of searching and... some use of the thing people hate (local only!) I came up with this script that works which I can copy for other devices:

-

#!/bin/bash

TARGET_ID="[drive ID]"
DRIVE_NAME=$(lsblk -o NAME,WWN -n | grep -F "$TARGET_ID" | awk '{print $1}' | sed 's/dev\///' | head -n 1)

if [ -z "$DRIVE_NAME" ]; then
echo "Error: Drive with WWN '$TARGET_ID' not found."
exit 1
fi

if [ ! -e /dev/${DRIVE_NAME} ]; then
echo "Error: Drive with WWN '$TARGET_ID' not found."
exit 1
fi

sudo blockdev --flushbufs /dev/${DRIVE_NAME}
sudo hdparm -Y /dev/${DRIVE_NAME}
echo 1 | sudo tee /sys/block/${DRIVE_NAME}/device/delete

-

I'm sure it could be cleaner (and I have echos I removed for space) and the second check may not be needed but it works.

Show threadNazoMar 1

@scott Ok, mounting with sync caused the drive to thrash. A lot. On a quite slow transfer... (I was downloading something from my server — not even a transfer from another filesystem.) So I guess sync isn't so great for a magnetic drive. Switching back to asynchronous made it go nearly silent. I guess it's able to order the writes better or something.

Hopefully the other suggestion will cover both bases sufficiently. I also tossed in a plain sync command to the mounted location before doing any of the rest of that stuff, so hopefully between all this I can be fairly certain. (Probably blockdev --flushbufs is the key thing though. This is just for good measure.)

Show threadScott VE3QBZMar 1
@nazokiyoubinbou yup, synchronous mode is quite slow :)
Show threadNazoMar 1

@scott It wasn't just slow. I expected it to be slow. Unbuffered being slower overall is a given.

It's the thrashing that bothered me. That sound means the head is having to move quite a lot. Which... didn't make sense. This was for a mere 6MB/s or so (the drive was limiting my download rate! The server is kind of slow — 11 or so is its max — and it limited it to about 6-7.) I remounted with async and hit resume and suddenly it goes almost dead silent and flares up to full speed. I hit sync and all that immediately after and there was basically nothing buffered. (This was with Filezilla which just doesn't use a lot of buffering.)

I can't really explain it. I just guess that the writes weren't well ordered when synced somehow. This was with btrfs though. Maybe it's the culprit.