Re: MAXNAMLEN vs NAME_MAX

2011-11-13 Thread David Holland
On Tue, Sep 27, 2011 at 03:48:29PM +0700, Robert Elz wrote:
| But it is better long term to move forward and allow for longer
| names.
  
  Why?

I was recently talking to some people who'd been working with some
(physicists, I think) doing data-intensive simulation of some kind,
and that reminded me: for various reasons, many people who are doing
serious data collection or simulation tend to encode vast amounts of
metadata in the names of their data files. Arguably this is a bad way
of doing things, but there are reasons for it and not so many clear
alternatives... anyway, 256 character filenames often aren't enough in
that context.

(This sort of usage also often involves things like 50,000 files in
one directory, so the columnizing behavior of ls is far from the top
of the list of relevant issues.)

If we do end up going through and doing a full set of compat functions
again, I think we should raise the limit to 1024... and maybe bump
PATH_MAX to say 4096 too.

  The 255 limit was just because that's how many bytes a one byte length
  field permitted, not because anyone thought names that long made sense.
  But if you're going to increase it, why  stop at 511?  That number
  means nothing - the next logical limit would be 65535 wouldn't it?

Well... yes but there are other considerations. As you noted, going
past one physical sector is problematic; going past one filesystem
block very problematic. Plus, as long as MMU pages remain 4K,
allocating contiguous kernel virtual space for path buffers (since if
NAME_MAX were raised to 64K, PATH_MAX would have to be at least that
large) could start to be a problem.

-- 
David A. Holland
dholl...@netbsd.org


Re: fs-independent quotas

2011-11-13 Thread Manuel Bouyer
On Sat, Oct 29, 2011 at 05:14:30PM +, David Holland wrote:
 [...]
3. Abolish the proplib-based transport encoding. Since it turns out
   that the use of proplib for quotactl(2) is only to encode struct
   ufs_quota_entry for transport across the user/kernel boundary,
   converting it back on the other side, it seems to me that it's
   a completely pointless complication and a poor use of proplib.
   It's also messy, even compared to other proplib usage elsewhere.
   (Regarding claims of easier/better compatibility, see below.)

Ho no, not again !

The arguments that ufs_quota_entry (or whatever its name is) will
be good enough for any future filesystem is just not true. We already
have been in this argument.

 
4. Abolish the xmlrpc-type user interface of quotactl(8) in favor
   of something else saner and easier to work with.

work with with *what* ?

 
 3. There's already been some discussion of the compat issues in this
 thread. Basically it boils down to: if you send a program material
 that it's not expecting to receive, it won't be able to cope with it
 and will fail/die/crash. This is true whether the material is binary
 or a proplib bundle or text or whatever else.

With a binary it'll probably crash. With a text-based format it will notice
the syntax error return an error code. This is a big difference,
especially for kernel.

 
 4. If using split on the output of quota/repquota/whatnot isn't good
 enough (in some specific places we may want a machine-readable-output
 option) then the best way to access the quota system from Perl or
 Python (or Ruby or Lua or ...) is with a set of bindings for the new
 proposed libquota. This should be straightforward to set up once the
 new libquota is in place. I think the current quotactl(8) should just

Are you going to provide those bindings ? I'm interested in perl.

 be dropped. Among other things, I've been told that XML-based user
 interfaces are specifically prohibited by act of Core.

I'd like an official word from core on this. I don't remmeber seeing
this stated anywhere.

 - As far as I can tell there is not and never has been support for
 manipulating quotas on unmounted filesystems.

There was in quoya(1), repquota(8) and edquota(8), and I've been using
it with netbsd-5. Just read the code in the netbsd-5 branch to see it.

-- 
Manuel Bouyer bou...@antioche.eu.org
 NetBSD: 26 ans d'experience feront toujours la difference
--


Re: bumping ARG_MAX

2011-11-13 Thread Hubert Feyrer

On Mon, 14 Nov 2011, Simon Burge wrote:

I think I like the Linux idea of a portion of stack size best


What is the stack size?
Is it what ulimit(1) gives me? The 2kB there seem pretty small for the 
problem at hand, and I can max. raise it to 64kB.



 - Hubert


Re: fs-independent quotas

2011-11-13 Thread Mouse
 The arguments that ufs_quota_entry (or whatever its name is) will be
 good enough for any future filesystem is just not true.

You have asserted that.

Proof by repeated assertion is...unconvincing.

Not that I think nuermic IDs will be good forever.  But, given the lack
of any _okther_ filesystem interfaces that represent such things as
strings, I think they are far enough off that it is much too early to
try to design them in here.

/~\ The ASCII Mouse
\ / Ribbon Campaign
 X  Against HTMLmo...@rodents-montreal.org
/ \ Email!   7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B


Re: bumping ARG_MAX

2011-11-13 Thread Joerg Sonnenberger
On Mon, Nov 14, 2011 at 01:32:24AM +0100, Hubert Feyrer wrote:
 On Mon, 14 Nov 2011, Simon Burge wrote:
 I think I like the Linux idea of a portion of stack size best
 
 What is the stack size?
 Is it what ulimit(1) gives me? The 2kB there seem pretty small for
 the problem at hand, and I can max. raise it to 64kB.

It is what ulimit(1) gives you, but that reports KB, not Bytes.

Joerg