Re: [prepatch] address_space-based writeback

Denis Vlasenko (vda@port.imtp.ilyichevsk.odessa.ua)
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/