On Fri, 20.01.12 23:14, Masatake YAMATO (yam...@redhat.com) wrote: > > If we go for advanced storage handling, we might need to invent > > something that can carry real metadata and assembly instructions, and > > this might need to live in their own files, sure. But that's a > > different issue, and would all be fine. But please leave fstab alone, > > we don't want to deal with changing that. > > > > Kay > > Thank you for explanation. > > systemd.mount(5) says: > > FSTAB > Mount units may either be configured via unit files, or via > /etc/fstab (see fstab(5) for details). > > systemd, which handles unit files for mount, already breaks the expectation > of the > random tools, doesn't it? The random tools don't know the unit files.
Which is why we don't really recommend anybody to use .mount unit files unless they really have to. That said, note that .mount unit files actually bring real benefit over fstab in some cases (i.e. since they allow you to control in very much detail the dependencies of the mount). But since those advantages are minimal (i.e. the automatic dependency logic should be good enough for most cases), we encourage everybody to just stay compatible and continue to use fstab. Extending fstab to fstab.d is neither compatible, nor does it bring any bigger advantages, and hence it's a bit pointless, don't you think? Or to turn this around: if you introduce an incompatible new interface, then that's OK, but then you have to offer some really really convincing new features to buy yourself a way out. Lennart -- Lennart Poettering - Red Hat, Inc. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel