Messages in this thread | | | From | Denis Vlasenko <> | Subject | Re: [prepatch] address_space-based writeback | Date | Fri, 3 May 2002 20:47:48 -0200 |
| |
On 3 May 2002 10:49, Helge Hafting wrote: > > > Yes, edit /etc/fstab. My file server has loads of partitions and it > > > exports them all and /etc/fstab on all clients just mounts them all. > > > Problem being? > > > > Problem is that I have to modify /etc/fstab on every workstation. > > So _automate_ that then. If you have so many workstations, make...
Yes I can do that easily. I meant that it is somewhat silly that clients have to be tweaked when normal directory on server become a mount point. It should be invisible from client.
(Before we start: I know about nohide)
> > It seems to me like the Bad Thing which is too old and traditional to > > change. :-( > > Most ways have their own disadvantages. Can you invent a better concept > than the inode that works as well in every existing way, and better for > this case? Your new syscall isn't it, as Pavel Machek demonstrated.
Pavel presented a corner case (tarring up thousands of files, all with exactly *same size*). It's like making pathological cases for VM behavior. I don't take that seriously, sorry. Another example?
> Changing unix is doable _if_ you can show a significant benefit. > The more utilities you want to break, the more benefit you need to show. > I don't think you can send the inode to the land of > "8-char limited passwords" by pushing "simpler management of fstabs" > though.
I'm afraid I can't present benefits big enough.
I was thinking of fs driver (NFS,reiser,NTFS,FAT,...) developers' pain, not about my /etc/fstab editing. -- vda - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |