186
votes
|
|
191
11
5
|
|
|
|
|
-14
votes
|
|
8
9
22
|
|
|
|
|
|
-4
votes
|
|
2
1
6
|
|
|
|
|
|
Attachments
No attachments.
Duplicates
Comments
|
|
|
If it's an internal drive, why would you NOT put it in fstab? This new "dynamic" system you are talking about is meant for removable drives (of which an internal HD is *not*).
|
|
chirag64
wrote on the 12 Jan 11 at 17:11
|
|
|
|
this is surely a must have....
|
|
|
|
This should be a hundred papercuts submission. Every time I set up an Ubuntu install it's one of the first things I do, and I shouldn't have to.
|
|
|
|
@Nickedynick are internal partitions not automatically added to fstab for you when you install ubuntu?
|
|
hirumono
wrote on the 16 Jan 11 at 11:06
|
|
|
@Darwin Survivor: Because it's something about system automatic configuration. It's not just about being able to mount/unmount a volume on the fly, removable or not; which is really a good thing, allowing the user to keep away data he isn't using and avoid data loss (let's remember every volume listed in fstab is checked every 30 mounts for security reasons; moreover, I feel happier if a volume was unmounted before a power outage).
Static fstab entries are now becoming obsolete, and this isn't just about removable drives: as I see it, Ubuntu is moving away from static conf files and towards total dynamic configuration of mounted volumes, as it already did with Xorg.conf (anyone remember those pages full of scan lines?). Let's think about UUIDs, allowing for unique identification of volumes independent of where they're connected: with this system I can remove an external HD (OK, I know it's not what you meant with 'removable' ;) ) and attach it to another controller, and next time I reboot the system will find and mount it without me editing a single line of text.
So here's why we should not put internal drives in fstab: to allow Linux to do something that Amiga already did in 1990. :D
|
|
hirumono
wrote on the 16 Jan 11 at 11:08
|
|
|
|
Sorry, I meant 'remove an INTERNAL HD' ;)
|
|
|
@hirumono ok, I see your point. I have a couple of questions though:
How does the new system allow drives to be unmounted before a power outage?
What does this have anything to do with the fsck check. Wich by the way is an *integrity* check, not a security check, and happens more often that once every 30 months (2 1/1 years).
|
|
hirumono
wrote on the 16 Jan 11 at 19:17
|
|
|
@Darwin Survivor: sorry if I wasn't clear enough, I meant that an unmounted drive would be safer in case of a power outage, and eliminating fstab lines allows to leave drives or partition unmounted if there's no need of them (thus increasing data security).
Yes, fsck is an integrity check which is carried out automatically every 30 mounts (not months... :D), that is, after the 30th time a volume has been mounted. It is a check that aims to prevent data loss due to various problems, including incorrect unmounting of the volume after crashes, poor cable connections, etc; let's say that the security rationale is 'if it was mounted, it could have been damaged'. Of course, limiting unnecessary access to a filesystem (i.e., not mounting it) decreases the chances to damage it.
|
|
|
ah, "mounts" makes much more sense :P
I am however confused by the fact that you are recommending leaving partitions unmounted to increase data security while at the same time your "solution" is to be able to mount partitions all the time. Just so you know, fstab lets you do it either way (by using or omitting noauto). I do however strongly support the current move the udev (it will take a while, but even k3b has been transitioned recently). I'm pretty sure the same thing can be done using udev rules to match the "noauto" system in fstab.
How would you recommend ubuntu remember these auto-mount settings? Should it update udev, take over udev and tell it when or when not to mount something?
|
|
hirumono
wrote on the 17 Jan 11 at 14:23
|
|
|
Well, my idea is to make frequently-used volumes automountable, while leaving less-used filesystem unmounted until the user needs them; so, in my mind, this would be a balance between ease of use and data security. And while fstab lines allow to do this, there is no user-friendly way to change this behaviour.
I marked the idea under "Nautilus" because, as it is the interface through which the user contacts udev, it would be the ideal target to implement the system on. Nautilus could keep a list of UUIDs and mount the corresponding volumes at login; even better, on detecting a new device it could ask the user whether it must be 'turned on' automatically every time. Like I proposed in the rationale, a 'mount at login' flag on the device properties (which, conveniently, are managed by Nautilus) would be the place where you could change the setting per-volume.
|
|
|
@hirumono Ok, makes sense. So if multiple people are logged in (graphically) and one person has the selected automount and the other hasn't, the automount would take precedence in your situation? I'm not saying this is bad, just clarifying.
Now I'm not sure how this affects non-fstab listed devices that are connected at boot time, but I know that if you plug a usb-key, usb-HD or external hd (esata), that ubuntu auto-mounts the device already. Are you not getting this behaviour, or is there something different if it's installed at boot time? (I don't have an ubuntu machine in front of me).
|
|
hirumono
wrote on the 17 Jan 11 at 15:50
|
|
|
@Darwin Survivor: I guess that every user to login would see his preferred devices automounted, together with the ones chosen by the previously logged users. Let's say User1 has devices 1 and 5 flagged as automountable, and User2 has 2 and 4: after User1 and User2 logged in, we would see devices 1, 2, 4 and 5 mounted, while device 3 would remain unmounted. Preference should go to offering every user easy access to his/her data.
Removable devices are auto-mounted per default (if you don't disable the option via Gconf). I am getting this behavour, regardless whether the device is installed at boot time; but it's different for volumes on non-removable HDs, which are correctly detected and installed but NOT mounted automatically at login.
|
|
|
Rather than having such an option in Nautilus, I would better see this as an enhancement in Palimpsest (System -> Administration -> Disk Utility). With a bit of improvement, one could be able to:
- manually configure the mountpoint of a filesystem (if he wants it to be mounted at some particular place instead of /media [which is intended for temporary mountpoints]);
- and using an opt-in/opt-out checkbox, could configure this filesystem to be automatically mounted.
This is something, IMO, that should definitely be part of Palimpsest.
|
|
MsG
wrote on the 20 Jan 11 at 01:52
|
|
|
|
People saying: HEY Why not put it in are _totally_ missing the point. Hello, it is Linux for Human Beings, which means that GUI-lovers also need to have an option to easily fix things like this.
|
|
Raval
wrote on the 20 Jan 11 at 01:52
|
|
|
|
I would give an arm and a leg for this feature. Every morning when I try to boot up an OS in VirtualBox I get errors because my Virtual hardrives are on a second HD that hasn't been mounted at startup.
|
|
hirumono
wrote on the 23 Jan 11 at 11:55
|
|
|
@AlexandreP: of course this is a feature that could be implemented in Palimpsest. Yet, I think that Nautilus would be the best choice for these reasons:
- Nautilus is the main interface between the user and udev, and allows to mount and unmount volumes in a transparent way (just accessing a volume calls the appropriate procedure to mount and access it). So, the first time a new volume is accessed, a window could pop up and ask "Would you like to keep this volume open in the future?". No need to call other applications, thus keeping it all simple.
- Palimpsest is a truly powerful utility (and I really love it!), but its use is not meant for simple tasks as mounting volumes, and though the automounting option could well fit into its interface, I believe it shouldn't be exclusive to it; after all, it is something that should come as a commodity, both for expert and inexperienced users, and the latter shouldn't need to tweak their system (with the risk of wreaking havoc with such a powerful instrument) just to decide the volumes to access more frequently.
|
|
|
|
@hirumono NO, no popups! If a user wants something auto-mounted, let them right-click the volume and select "auto-mount when connected". Making every user deal with a popup (even if it's only the first time a unique device is connected) is ridiculous. Just think of when someone goes to work or school and people are moving some files around with USB drives, having to cancel a popup every time would be SERIOUSLY time consuming!
|
|
hirumono
wrote on the 26 Jan 11 at 19:37
|
|
|
@DarwinSurvivor: XD Maybe popups carry a nasty smell of Windows with them - especially Vista and 7 ;)
Well, that wouldn't really be the scenario, because USB drives are removable devices and are automatically mounted every time; the popup would come out only the first time a *non-removable* volume got mounted. So, unless you share my degree of insanity and own 10 non-system partitions (on 2 physical drives), that means the average user, who probably has a Windows partition, maybe a Fat32 swap space and/or a second HD for data storage, would see the popup 2 or 3 times at most.
However I understand your point; modern OSes are far too intrusive and annoying about that "friendly" interaction with their users, so maybe a popup isn't the right way. What do you think about it?
|
|
|
Just for clarification, what makes something a "removable drive"?
I'm assuming USB keys would be removable and internal HD's non-removable. What about usb harddrives and e-sata or sata harddrives? Many computers now have slots in the front where a normal hard-drive can be slid in and connected immediately via sata connectors.
|
|
hirumono
wrote on the 26 Jan 11 at 20:45
|
|
|
|
Yes, USB hard drives, eSata, Firewire, even some tray-fitted HDs are all removable devices because of their 'hot-pluggable' status, i.e. their interface allows them to connect to the system bus 'on the fly' (that is, when the system has already booted) and to detach without any consequences from a live system, provided their filesystem has been correctly unmounted. To be more clear, think about taking a plain ATA HD and connecting it to your live system. The ATA bus would instantly freeze and you would be forced to reset your machine. The same would happen if you disconnected a working HD from its ATA cable (shivers are running on my back just now). Removable devices are designed to allow connection and removal without any consequences, by sending a 'disconnect' signal to the interface which, in turn, powers the device off.
|
|
|
|
Sata is hotswappable, even the internal drives. Would this mean that all drives in a sata-enabled system are considered "removable" now?
|
|
hirumono
wrote on the 27 Jan 11 at 14:05
|
|
|
|
No, not all SATA drives are hot-swappable; the controller must support this feature and the OS must be able to control it.
|
|
|
Solution #2:
Idea #323: "Disk Manager by default".
|
|
|
I didn't know about Disk Manager. A more popular tool to achieve its same goals seems to be pysdm, which is also reported in Ubuntu Help. Both of them, however, rely on the same thing: static fstab entries. Moreover, both ask for the user to launch a system sofware (with super-user authorizations) and tweak their volumes manually, which may lead to unpleasant results and could be seen as complicated/dangerous by a novice.
If Ubuntu is to ultimately move to automatic management of volumes, a dedicated tool to use fstab lines is not the optimal solution. I don't know if something similar exists to create udev rules; yet, I believe that even those could be redundant for everyday use, and should be left to experienced users who know how to tinker with their filesystems - and what to expect in case of failure.
|
|
saimanoj
wrote on the 13 Feb 11 at 10:33
|
|
|
Why is my idea demoted??
Please tell me the reason..
|
pitti
(Ubuntu developer)
wrote on the 20 Apr 11 at 15:05
|
|
|
I discussed the idea with David Zeuthen, who is the main GNOME/plumbing developer for handling storage in GNOME.
We both agree that it is a good idea to offer automatic mounting of internal drives in the desktop. However, we really want to avoid introducing a per-user configuration and use the already existing /etc/fstab for the following reasons:
* /etc/fstab has been the canonical location for (manually) configuring drives for many decades, and thus we should keep it instead of introducing a parallel configuration hierarchy in e. g. per-user gsettings.
* Configurations from different users can collide.
* Per-user settings don't allow us to offer automount on boot.
So the plan so far is to provide a configuration API to the udisks daemon (in version 2) which will manipulate /etc/fstab directly. Then the "Disk Utility" program (from gnome-disk-utility) will grow some UI similar to:
Automatically mount this drive:
( ) Never
(X) When I log in
( ) On computer startup
It won't be in nautilus' volume properties, as in GNOME 3 the user interface is quite different.
The timeline for this is somewhere in GNOME 3.4, i. e. in about a year.
|
|
hirumono
wrote on the 20 Jun 11 at 20:24
|
|
|
@pitti: I'm very happy to see that my idea was useful and will be implemented! :) Thanks for your reply. (I noticed it just now - it's been quite some time since I visited this thread.)
Please allow me some considerations though: isn't the fstab approach a bit outdated? When Ubuntu moved its first steps, fstab was the only rule and I used to tweak it to my tastes; then Udev came and fstab was largely forgotten, in the name of a more dynamic approach, and I had to use gnome-mount, which was later abandoned, so I had to come up with another solution I can't remember now... Would it make sense to return to fstab entries now?
Please don't get me wrong; I understand that introducing another configuration 'layer' would be unpractical and redundant. I don't know how fstab lines would 'marry' with Udev either; last time I tried this approach (after upgrading to some version of Ubuntu that didn't automount all my partitions like its predecessor did), my devices were mounted correctly but couldn't be unmounted from Nautilus, as the system complained about me not being root (though I used the 'user' option. Could have been a fault from my side, though.)
|
Post your comment
|
