[lkml]   [2003]   [Aug]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: FS: hardlinks on directories
On Mon, 4 Aug 2003 18:54:35 +0200
Herbert Pötzl <> wrote:

> On Mon, Aug 04, 2003 at 06:35:45PM +0200, Stephan von Krawczynski wrote:
> > On Mon, 4 Aug 2003 18:16:57 +0200
> > Herbert Pötzl <> wrote:
> >
> > > on the other hand, if you want somebody to implement
> > > this stuff for you, you'll have to provide convincing
> > > arguments for it, I for example, would be glad if
> > > hardlinks where removed from unix altogether ...
> >
> > Huh, hard stuff!
> >
> > Explain your solution for a very common problem:
> >
> > You have a _big_ fileserver, say some SAN or the like with Gigs.
> > Your data on it is organized according to your basic user
> > structure, because it is very handy to have all data from one
> > user altogether in one directory.
> I already do something like this, although not for thousands
> of users, but I guess this would scale well ...
> consider a storage device (maybe a partition) for each
> category of data you want to store/provide/serve
> /mnt/webspace, /mnt/database, /mnt/email, /mnt/wossname ...

I have one objection: it is the poorest possible implementation in terms of
storage usage. You may have TBs free on database and ran full on webspace,
fluctuation on email is dramatic. You waste a damn lot of resources with this
I consider it usable but inferior in terms of costs and scalability. One can
very well argue you have to waste bucks to avoid hardlinks (which you don't
have at this point). Not having hardlinks costs obviously more. In fact a very
good commercial argument pro hardlinks.
If you have all your partitions only logically organised on one SAN you have to
remount via nfs quite a bit to get things in the right trees. That does not
sound like a performance setup. Did you manage to remount "mount --bind"

and ...

> on the access server (where the customer maintains the data)
> you'll end up mounting all the storage categories, required
> for access and you do an additional restructuring for each
> customer (which of course is automated)
> /home/customer/charlie is populated with symlinks to
> /mnt/*/customer/charlie named by category
> /home/customer/charlie/webspace -> /mnt/webspace/customer/charlie
> /home/customer/charlie/email -> /mnt/email/customer/charlie
> ...

which basically means on your access server you have to follow symlinks which
is yet another security issue in itself.

Basically you avoid a clean hardlink-setup with a symlink-setup rising possible
security drawbacks and a lot of remounting to get things straight...
I am not really convinced.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:47    [W:0.118 / U:2.884 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site