get UUID of a drive

Linux (*buntu) now seems to be mounting all drives by their UUID so they can move around in the system and not be bound do their controller location (e.g., sda1).

So how do you get the UUID of a drive?

a) sudo tune2fs /dev/aaa# | grep UUID (e.g., sudo tune2fs /dev/sdb1 | grep UUID)
b) ls -l /dev/disk/by-uuid>/code>

Very cool. That UUID can then be used to edit the /etc/fstab to enter a drive by UUID just like the installer does.

I found both of these over here. I'm not quite that smort on my own... ;^)

Advertisements

About John

I write about technology interests, cooking, and my own writing (sci-fi and fantasy... sometimes both). I try to keep things light, but sometimes I get side-tracked on an issue that I feel strongly about. No offense is meant, I'm just like any other person who feels strongly about something when I write. View all posts by John

6 responses to “get UUID of a drive

  • Jon P.

    Hi John,

    Since you seem to be on a hard drive kick this month and you have teased about SSHing into your ix2 – and comments are closed on that post – I’ll ping you about that here. 🙂

    I, too, have a straight ix2 (no “-xxx” or “Pro” suffix, just the straight 2x500gb entry-level jobby) and while I’ve found it easy to use and reliable enough, it is SLOWWW when you start getting into moving/copying gigs worth of files.

    The problem as I understand it is that the processor in the critter can basically only handle ~12MB/s inbound, ~22-24MB/s outbound worth of traffic.

    Copying/moving files via CIFS shares (I’m currently all Windoze) quickly saturates that bandwith and makes the process sheer torture – about 24 hours (!!) to move ~300GB worth of files *within the same NAS*.

    Trust me when I say that there’s nothing wrong on the network side – cabling, nics, switches, etc. all run gigabit ethernet just fine.

    Switching 100mbs-only devices out of the loop and enabling end-to-end jumbo frames doesn’t help either (although large file transfers *everywhere else that doesn’t involve the NAS* start burning up the wires, hehe) – again, this seems to be a problem with the NAS processor.

    Well, I say “problem”, but I don’t mean there’s anything technically wrong, it’s just that they chose a cheap processor solution to keep the ix2 in perceived soho pricing range and it simply can’t keep up.

    To cut this short, if you can come up with a sure way to crack into it and access the bleepin’ CP and MV commands for at least intra-NAS file manipulation (nothing can be done about the network transfer aspect), you’d definitely have my, and probably multiple Iomega forum posters, eternal gratitude.

    I’m a *nix tyro but can follow most discussions on it, and I imagine anyone from the Windows world who would be willing to follow your directions probably can do the same – I’ll load up a Ubuntu VM if necessary to get ‘er done. 🙂

  • John

    John P.,

    Thanks for the thoughts! So far, I have been happy with the ix2’s transfer speed, but I don’t move nearly that much data at once. I also use it in mirrored mode, so I’m not worried about moving things from drive to drive in it.

    However I do find that to be a shortcoming, just like the inability to copy things directly off a connected USB device. You have to use a “client” machine to perform that copy. Obviously, that becomes a burden to the network. If that device is mounted on the ix2, there has -got to- be a way to get to it.

    The first trick will be in figuring out what derivation of Linux they use on this. But to do SSH, I have a feeling that would require a way to flash the device with a different firmware — something that included SSH.

    I read somewhere that someone was able to issue CLI commands through one of the screens with some trick. I haven’t tried that yet, but it will be fun to poke at… when I have time.

    When I get around to experimenting, I’ll certainly post about it.

  • John

    This is what I found before. It seems like SSH is present, but disabled.

    http://www.smallnetbuilder.com/content/view/30642/75/1/4/

    When I have a chance, I am certainly going to try this! How cool would that be!?

    • Jon P.

      The coolness would be right up there – doesn’t seem to be many folks who’ve tried it. The link you referenced was the only one I could find about hacking it as well.

      FWIW, I don’t think you’d need to flash the drive’s firmwarm – IIRC, Iomega actually released GPL’ed code for the underlying OS from what I saw in their forums, which would probably be enough for you from what I’ve gathered from other posts of yours – I’ll see if I can find the links.

      It’s not taking time to move from disk to disk per se – I chose to set mine to RAID 0, so for all intents and purposes it’s a “single” drive like your RAID 1 is – it’s trying to move files among the shares located on that NAS that would benefit the most from your efforts (if successful).

      Trying to do copy/move operations from client Windoze machines doesn’t allow the NAS to use it’s built-in interprocess file handling: every source file byte has to route back to the client machine then back to the NAS before being recreated at the destination share, with all the attendant network chatter packet overhead sucking up yet more of that precious 12/24MBs bandwith, leaving effective file throughput way down.

      Whereas a MV issued on the NAS itself would essentially just rewrite file pointers and voila – gigs of data “moved” in seconds. 🙂

      Alternatively, it may be easier to somehow make the root share folder itself available for sharing/drive mapping: Windoze would then be able to correctly rewrite locations instead of doing what it does now.

      E.g. currently the ix2 does:

      ??\\share\backup
      ??\\share\public
      ??\\share\user1\shared1 (shared2, etc.)
      ??\\share\user2\shared1 (shared2, etc.)
      etc…

      You can map user1\shared1 to X:, and user2\shared1 to Y:, (or just access them via their UNCs), and Windows (correctly) thinks they are physically separate shares and does the full monty network copy/move mess.

      But if you can map \\share itself to a drive letter and set permissions on all the user shared folders below to allow access, Windows would be able to copy/move directly via FAT rewrites with something like:

      C:> move z:\user1\shared1\*.* z:\user2\shared1

      Good luck in either case!

      • Jon P.

        Update:

        Heh, that was easy – they have their gpl’ed code available for d/l in their ix2 support section:

        http://download.iomega.com/english/emc-lifeline-2.0-gplcomponents.tar

        Just a quick glance through it shows something interesting – assuming they stripped the heck out of the distro to keep it lightweight, I noted a gz referencing iSCSI… wonder if that’s something they intended to implement or couldn’t implement but left the supporting files in “just in case” somebody else wanted to take a crack at it?

        And correction: I said I had my drive in raid 0 mode – I meant JBOD mode. Sheesh. Same difference, either mode would appear as a “single” drive, of course.

      • John

        I think I now see what you are getting at. This seems to be an issue with shared drives overall. The “client” machine is controlling the file move or copy instead of doing something like queuing a request to the NAS host to perform the move.

        This is an issue I have pondered a few times. Clearly this is a reason why being able to SSH into a machine would be handy.

        I have hit this problem VPN’ing into very remote sites with slow connections. Being lazy and using a UNC connection to servers to access and move files has always reminded me how dumb that is. [remote source]-to-[my machine]-to[remote target on same network as remote source] … I might as well just copy the files to my machine in whole and then copy them back.

        What would be even nicer — and would be a bit of revolution in file shares — would be if the file share protocol would recognize a mv or cp to the same device and queue a request to the device host to perform the operation. Taking it a step further, it would be nice if it would also be able to do that to any device on the same network. That, I think, is a bit beyond the basic mounted share. A very interesting idea though… now I need to look around and see if such a thing exists, even if it is in an enterprise solution.