Re: MAXNAMLEN vs NAME_MAX
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
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
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
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
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