Can you mount/unmout hard drives that are powered and connected to the raspberry pi via a usb hub
Yes, whether they are connected and powered via a hub or not is irrelevant to everything explained here. All USB ports are parts of USB hubs -- just the build in ones aren't in a separate enclosure, etc. Daisy chaining hubs is possible, which is what you are actually doing when you attach an external one.
I'm dubious that you will be able to power two drives from a Pi, but then I have not tried and haven't researched what's available in terms of power requirements. As per my comments, there is not much point in looking for a high performance drive as that potential is going to be wasted; the Pi's ports are USB 2.0, with a max throughput of 35 MB/s. I have very seldom seen transfers get close to that. Also, this theoretical maximum is for all four ports combined, plus the ethernet jack if in use.
So you might as well look for low power and cross your fingers. By default new models are capable of up to 1200 mA total from the USB, but except for the Pi 3, by default are limited to 600 mA. This may or may not be enough to power one drive; certainly it's common for people to complain here that it doesn't work until they add:
/boot/config.txt and reboot.
Is it possible to automount one drive on the usb hub to the filesystem and only periodically mount the other one for a limited time?
Yes, you can do whatever you like along those lines. Personally I am not a fan of generic automounting (the kind that just mounts anything as soon as it is plugged in), and always disable it completely, so I am not sure what is possible there with regard to e.g., not mounting one drive in particular, although obviously you can unmount and remount something manually.
I believe automounting is usually a feature of desktop environments, so if you are running the Pi headless you will not need to worry about it. With regard to mounting a particular drive, we of course aren't really talking about drives, we're talking about partitions. A fairly simple way to arrange for a particular partition to be mounted is via udev rules and partition UUIDs. You'll find lots of examples of this online if you search for "linux udev uuid"; I actually don't do it exactly that way anymore and instead use a pair of rules like this:
KERNEL=="sd[a-z]" ACTION=="add" RUN+="mything.pl"
KERNEL=="sd[a-z][0-9]" ACTION=="add" RUN+="mything.pl"
Which is really a catchall for anything, i.e., it could be used to implement automounting. These are added in a file to
/etc/udev/rules.d and should be applied after you run
sudo udevadm --reload-rules
Udevadm has various useful subcommands such as
udevadm monitor, see
Anyway, with regard to UUIDs, to find them, use
blkid. They are per partition, but I believe actually an aspect of the filesystem, and it is the
UUID you want to use, not the
PARTUUID. If the filesystem does not have one you may be able to assign it with
tune2fs depending on the filesystem type.
mything.pl is really not important here (that's where I filter by UUID; note udev can get fairly complex in terms of information it hands to this process via environment variables; there's lots of reading about udev available online and it is easy to play with, although there may turn out to be a lot of confusing "gotchas").
What is worth noting is that for the drive I keep mounted 24/7 on a pi, I like to configure it to spin down while not actively in use. It then uses no power and should appear to be off (no sound, vibration, etc.). If the drive is capable of this and obeys standard protocols, this can be done with
hdparm (you have to
apt install hdparm first). For example:
hdparm -B 127 /dev/sda
hdparm -B 241 /dev/sda
Will set the drive (notice, that's a device node again, not a partition) to power down after 30 minutes of inactivity.
You do not have to unmount any filesystems to do this. What will then happen is as soon as the filesystems are accessed, the drive will be activeated by the OS again. This will cause a second or so delay.
Although linux in theory has drivers for a wide range of filesystems, not good things are often said about the NTFS support, including the fact that it is processor intensive, so unless you have a reason to use that you probably should avoid it. To be fair, however, I'm not a windows user so avoid it anyway.
VFAT is probably the most portable, but depending on what the drives are to be used for the current linux native filesystem, ext4, is probably the best choice. If you do this, be sure to mount with:
mount -o noatime
This prevents recording of access times for files, which amount to unnecessary writes when reading. You can also set options like this via