Quoting Ilya Konstantinov, from the post of Thu, 14 Nov:
> > and EVMS and such professional tools to manage the space (so we can
> > dynamicly allocate hard limits to certain mirrors, and an overflow
> > in RedHat doesn't cause Debian to stop mirroring :)
> 
> Are you sure about that? Shouldn't the space those partitions take
> stay continuous, which limits possibilities of resizing?

and why is that?

> 
> This approach to use partitions to solve lack of per-directory quota
> looks like using the wrong tool for the job.

not too sure. each mirror sits on a different device and cannot expand
byond it. if needed, some unallocated space is added to the device and
the filesystem is resized, but the kernel keeps your mirror on a leash.

wrong? maybe. but this is what unix offers as directory quota and it's
not bad at all.

> There's also a possible "low-tech" solution -- to periodically check
> disk usage of each limited directory, and disallow user 'mirror' from
> writing to it (by setting file permissions) as soon as it hits the
> limit.

that's no low tech at all, that's actually higher level, where you stop
info overflow logicaly rather than physicaly. it will mean writing a
bunch of tricky scripts, maintaining them, removing locks manually once
problems are solved, etc. etc. I see a lot of flows and design problems
in this, and way more babysitting. I still opt for growing devices.

that's beside the point. first we need a few new disks. on Sunday my
boss returns from a show in San Francisco so I'll bounce the idea off
him. I am starting to think we might as well move to a new server and
keep the old machine as ftp2.iglu or something.

yet another option is, ofcourse, to talk to Alex Landsberg who now works
in Ligad, and ask him for a change of disks to bigger sizes or even
upgrade the entire machine. I have his phone number on my dialer and can
call him on say, Sunday. you guys roll the idea in your heads for a
while and tell me what you think.

-- 
Maintainability consultant
Ira Abramov

http://ira.abramov.org/email/ This post is encrypted twice with ROT-13.
Documenting or attempting to crack this encryption is illegal.

Attachment: msg00840/pgp00000.pgp
Description: PGP signature

Reply via email to