questions regarding hot-plug capable devices

[unreal4u]

Hi everybody

just a few little questions ...

first one:
i have noticed that the sata and external usb hot-plug devices, until you not unplug them physically, don't stop the internal motor that makes the platters spin. Does this happens too in SCSI devices ? Do they stop the motor BEFORE you unplug them ?

second one:
Assuming linux 2.6+ kernel, when you umount an hot-pluggable device, does that actually move the heads to the safe sector so you can carry the drive safely ?

Greetings !!

 

[unreal4u]

i don't know if it's allowed to do ups here in hardocp .. but if not, please ignore this one

 

[drizzt81]

i don't know if it's allowed to do ups here in hardocp .. but if not, please ignore this one

usually not a problem. You appear impatient however. It is a holiday in the USA and this subforum is not visited that much anyway, on top of which it is the middle of the night for quite a bit of the USA now.

 

[unreal4u]

usually not a problem. You appear impatient however. It is a holiday in the USA and this subforum is not visited that much anyway, on top of which it is the middle of the night for quite a bit of the USA now.

i'm sorry, i live in Chili, so i didn't even knew it was a holiday in the USA ... in chili it is now 4AM, so as you can probably guess, i work better at night lol ... but in fact, yes, i'm a little impacient, some friends recommended me this forum because of it's high technical knowledge (and yes, this forum is like heaven for me, i've found many technical answers already) and it's way much active than it would be in any other forum around the world so late ...

Thanks for your quick response

Greetings !!

 

[hokatichenci]

It's typically unsafe in Linux to just yank a drive out, umount I don't believe will stop the motor or put it to a safe position, the umount is there for making sure the filesystem gets all of its data flushed safely so that the filesystem is intact. So long as nothing is being written to the disk while unmounted, I doubt much could come of it if you just yank it.

You could of course, just always test it before you put any significant data on it to make sure it works as expected.

 

[unreal4u]

It's typically unsafe in Linux to just yank a drive out, umount I don't believe will stop the motor or put it to a safe position, the umount is there for making sure the filesystem gets all of its data flushed safely so that the filesystem is intact. So long as nothing is being written to the disk while unmounted, I doubt much could come of it if you just yank it.

You could of course, just always test it before you put any significant data on it to make sure it works as expected.

as for SATA and USB drives, it does not stop the motor (tested already, in windows and linux, both the same results), but i'm also unsure if it takes the heads back to the safe sector, and that's what would really scare me ... it would be a lot safer to carry my brand new 60GB "pendrive" if i'm sure it takes back the heads ...
yesterday something strange happened: i did umount /dev/sdc but it wouldn't let me ... had to try umount -f /dev/sdc (-f = force it)

i know that if the motor stops, the drive would take the heads to the safe sector, and that's why i'm really asking if that happens in SCSI drives, which should be more advanced in this kind of things due to years of experience ...

Greetings !!

 

[hokatichenci]

Is the safe sector something that you are thinking about or is there something real that I havn't heard about in SATA drives? I doubt the proper shutdown in Windows would be incorrect, since they would be under a serious amount of pressure (read: lawsuits) if they were unintentionally causing serious damage to these hd's.

 

[drizzt81]

Western Digital says that their harddrives have automatic head parking, which ought to improve non-operational shock resistance. It may be that the stored charge in the capacitors is used to park the head when the supply power is lost.

 

[unreal4u]

every ide and sata hdd drive has a safe sector, please take a look at these two images:

in image N° 1, u can see a typical hard drive while in operation ...

on image N° 2, u see a hard drive while it's been properly unplugged ... well .. this is the safe sector, (on many hdd's it's common to see that the safe sector is on the inner circle of the drive), and that's the zone where you can safely carry the drive, because without it, with the vibrations, you could easily make a scratch on the platters ... (do you have seen that most drives say: "this drive cannot experience shocks in excess of 300G"?)

That is also the reason why SSD can easily take shocks in excess of 1000G ( !! ) because it doesn't have any mechanical parts that could scratch the platters ...

Another fact: when you turn off a linux box (or a windows one, properly off course) one of the last messages you can see is: "shutting down hda" (or sda if you have a SATA drive), well, the energy is not cutted to the hard drive until the PSU cuts all general energy, what's done in this step, is taking the head towards the safe sector ...

Greetings !!


@ drizzt81: that could maybe be the answer to my question will look at seagate's site if that same technology is implemented into the momentus series ... thanks a lot !!

 

[unreal4u]

well ... after some research, what drizzt said about the technology in WD's HDD, it's applied in all modern drives ...

Greetings and thanks for the answers

 

[hokatichenci]

well ... after some research, what drizzt said about the technology in WD's HDD, it's applied in all modern drives ...

Greetings and thanks for the answers

I don't know if you've had any luck under Linux with hot swapping, but my test file server is having a ton and a half of problems with it. Quite simply, it does not work. SATA detachments work fine, SATA reattachments are recognized by I guess the underlying libata, but udev is not connecting the dots, and therefore no device nodes are being created, meaning you get nothing.

The problem is written out a bit more in detail here:
http://forums.gentoo.org/viewtopic-t-523012.html?sid=e75e5f34c7adeabae7f42b403f679434

I tried the following kernels with no luck (udev 103):
Gentoo Hardened 2.6.18
Gentoo 2.6.19-r1
2.6.19-rc6-mm
2.6.19-git12

If you find a way to make it work with sata_nv, pm me, write me, mail me a letter, send a monkey to my place whatever. I really want this to work

 

[unreal4u]

i'm not @ home right now, but when i get home, i'll try on my debian etch box ...

in any case, i'll be reviewing some USB enclosures drives, not SATA ... so i guess there will be no trouble ...

Greetings

When the review is ready, i'll post the links (is it allowed to link to external sites )

 

[hokatichenci]

i'm not @ home right now, but when i get home, i'll try on my debian etch box ...

in any case, i'll be reviewing some USB enclosures drives, not SATA ... so i guess there will be no trouble ...

Greetings

When the review is ready, i'll post the links (is it allowed to link to external sites )

USB is totally hot pluggable. Good luck with that.

 

[unreal4u]

USB is totally hot pluggable. Good luck with that.

well ... i've found some troubles when booting with some USB enclosures in debian, it seems that it doesn't properly recognize and stays eternally trying to find it ... once the booting is done, i can't mount the drive and have to reboot without the drive connected ... really don't now why that happens and if it's a problem of my kernel (2.16.xx-K7) or not ... i have until dec 22 to find out what's happening there ...

Greetings

 

[Bones]

I don't know if you've had any luck under Linux with hot swapping, but my test file server is having a ton and a half of problems with it. Quite simply, it does not work. SATA detachments work fine, SATA reattachments are recognized by I guess the underlying libata, but udev is not connecting the dots, and therefore no device nodes are being created, meaning you get nothing.

The problem is written out a bit more in detail here:
http://forums.gentoo.org/viewtopic-t-523012.html?sid=e75e5f34c7adeabae7f42b403f679434

I tried the following kernels with no luck (udev 103):
Gentoo Hardened 2.6.18
Gentoo 2.6.19-r1
2.6.19-rc6-mm
2.6.19-git12

If you find a way to make it work with sata_nv, pm me, write me, mail me a letter, send a monkey to my place whatever. I really want this to work

Funny you should bring this up, I just tested SATA hotswap yesterday. I'm using nv_sata with a vanilla 2.6.19 kernel (built in, nota module). Everything just works, except I had to mount the filesystem by hand. Udev created and destroyed the device nodes just like it should. Not sure what is wrong with your setup

On a related note, udev won't necessarily make the same node in /dev each time you plug something in, unless you've manually tweaked your rulesets. So a static fstab doesn't work very well for mounting SATA hotswaps. My solution was to convert all of the /dev/sdxx in fstab to filesystem UUIDs, so that a simple "mount /mnt/whatever" does what you'd expect.

 

[hokatichenci]

Funny you should bring this up, I just tested SATA hotswap yesterday. I'm using nv_sata with a vanilla 2.6.19 kernel (built in, nota module). Everything just works, except I had to mount the filesystem by hand. Udev created and destroyed the device nodes just like it should. Not sure what is wrong with your setup

On a related note, udev won't necessarily make the same node in /dev each time you plug something in, unless you've manually tweaked your rulesets. So a static fstab doesn't work very well for mounting SATA hotswaps. My solution was to convert all of the /dev/sdxx in fstab to filesystem UUIDs, so that a simple "mount /mnt/whatever" does what you'd expect.

I backported a patch from 2.6.19 that forces hard resets and everything works actually. I think 2.6.19git and mm were just too unstable to work (ACPI problems maybe? who knows). The way the kernel adds them is that it adds to the highest system (I havn't tested if theres an empty slot, ie sda and sdc but no sdb). I did however write some simple udev rules to handle symlinking so I'll know which port is which sd[a-z]. You could probably make this a one liner with a call-name program (%c), but since I don't want to mess with it too much I just use the individual rules per port.

KERNELS=="0:0:0:0", SUBSYSTEMS=="scsi", SYMLINK+="raid/1d%n"
KERNELS=="1:0:0:0", SUBSYSTEMS=="scsi", SYMLINK+="raid/2d%n"
KERNELS=="2:0:0:0", SUBSYSTEMS=="scsi", SYMLINK+="raid/3d%n"
KERNELS=="3:0:0:0", SUBSYSTEMS=="scsi", SYMLINK+="raid/4d%n"
KERNELS=="4:0:0:0", SUBSYSTEMS=="scsi", SYMLINK+="raid/5d%n"
KERNELS=="5:0:0:0", SUBSYSTEMS=="scsi", SYMLINK+="raid/6d%n"
KERNELS=="6:0:0:0", SUBSYSTEMS=="scsi", SYMLINK+="raid/7d%n"
KERNELS=="7:0:0:0", SUBSYSTEMS=="scsi", SYMLINK+="raid/8d%n"

That'll give you /dev/raid/[1-8]d{1-16}

 

[Bones]

Those are some handy udev rules. I've never delved into udev much until yesterday, and you just saved me a bit of research. I have a six disk fileserver, four disks in RAID-5, the others separate. I was planning on adding a hot standby disk for the RAID, and possibly another removable drive for backups. I was having a nice time dealing with the /dev node changes across reboots with the different hardware setups - the root disk kept moving on me, so I started looking into fstab UUIDs, udev, and hal. Looks like I'm spending the next few days reading documentation.

My only gripe now is that I can't seem to pass a UUID for the kernel root parameter, the kernel insists on a /dev node. Every time the boot disk moves, I need to spend a tedious few seconds messing around with grub to find the disk