On Tue, Jul 17, 2012 at 09:30:52AM +, Emmanuel Dreyfus wrote:
> > You also need to make sure that the kernel knows how many references
> > to C it's been given, so it can drop that many when it calls
> > PUFFS_RECLAIM.
>
> Do you mean I should have the kernel conunting successful lookups,
On Wed, Jul 18, 2012 at 09:18:49AM +0200, Francois Tigeot wrote:
> > > I would also guess that sparse files are very rarely used. But for
> > > disk usage purposes you want to consider real disk usage including
> > > overhead because the quotas are mostly used to partition the available
> > > s
On Wed, Jul 18, 2012 at 08:53:24AM +0200, Francois Tigeot wrote:
> On Tue, Jul 17, 2012 at 08:29:10PM +0100, David Laight wrote:
>
> > Many moons ago someone change unixware so that 'ls -s' reported a
> > value based on the file size - not the number of block used.
> > Really wasn't a good change a
On Wed, Jul 18, 2012 at 12:37:58PM +0100, Roy Marples wrote:
>
> + if (p != NULL && P_ZOMBIE(p)) {
> + mutex_exit(proc_lock);
> + return 0;
> + }
> mutex_exit(proc_lock);
>
On Wed, Jul 18, 2012 at 12:11:10PM -0400, Mouse wrote:
> >> Um, why would anything quota-related ever cause errors from lseek?
> > Because he applies quotas to file length. The lseek is what will
> > take you over quota, whether you ever write or not.
>
> At least in my experience, lseek never af
On Jul 18, 2012, at 12:11 PM, Mouse wrote:
>>> Um, why would anything quota-related ever cause errors from lseek?
>> Because he applies quotas to file length. The lseek is what will
>> take you over quota, whether you ever write or not.
>
> At least in my experience, lseek never affects any fil
>> Um, why would anything quota-related ever cause errors from lseek?
> Because he applies quotas to file length. The lseek is what will
> take you over quota, whether you ever write or not.
At least in my experience, lseek never affects any file's size. lseek
such that the file pointer is left
On Wed, Jul 18, 2012 at 11:35:57AM -0400, Mouse wrote:
> > So both because you can count too much (and break applications that
> > suddenly get impermissible errors from lseek)
>
> Um, why would anything quota-related ever cause errors from lseek?
Because he applies quotas to file length. The ls
On Wed, 18 Jul 2012, Mouse wrote:
> Subject: Re: Syscall kill(2) called for a zombie process should return 0
>
> > + if (p != NULL && P_ZOMBIE(p)) {
> > + mutex_exit(proc_lock);
> > + return 0;
> > + }
> >
> So both because you can count too much (and break applications that
> suddenly get impermissible errors from lseek)
Um, why would anything quota-related ever cause errors from lseek?
Maybe from a write immediately afterwrards, but from lseek?
/~\ The ASCII Mouse
\ /
> + if (p != NULL && P_ZOMBIE(p)) {
> + mutex_exit(proc_lock);
> + return 0;
> + }
> mutex_exit(proc_lock);
> return ESRCH;
> This is a general question, not
On Wed, Jul 18, 2012 at 08:44:33AM +0200, Francois Tigeot wrote:
>
> As far as I remember, potential application breakages concerns didn't come
> up when the decision was made to not specially handle sparse files.
>
> I may have to it if the first implementation really causes problems in
> practi
On 18/07/2012 12:53, Roger Pau Monne wrote:
> Roy Marples wrote:
>> On 18/07/2012 11:46, Roger Pau Monne wrote:
>>> Please review the attached patch.
>>
>> +if (p != NULL && P_ZOMBIE(p)) {
>> +mutex_exit(proc_lock);
>> +ret
Roy Marples wrote:
> On 18/07/2012 11:46, Roger Pau Monne wrote:
>> Please review the attached patch.
>
> + if (p != NULL && P_ZOMBIE(p)) {
> + mutex_exit(proc_lock);
> + return 0;
> + }
>
On Wed, Jul 18, 2012 at 12:37:58PM +0100, Roy Marples wrote:
> On 18/07/2012 11:46, Roger Pau Monne wrote:
> > Please review the attached patch.
>
> + if (p != NULL && P_ZOMBIE(p)) {
> + mutex_exit(proc_lock);
> + return 0
On 18/07/2012 11:46, Roger Pau Monne wrote:
> Please review the attached patch.
+ if (p != NULL && P_ZOMBIE(p)) {
+ mutex_exit(proc_lock);
+ return 0;
+ }
mutex_exit(proc
I have the issue of processes stuck sleeping for uvn_fp2 after a PUFFS
ffilesystem crashed. No way to kill -9, and no way to remoune the
filesystem, since the mount point is busy.
Here is the process backtrace, in case someone has an idea on how to
make that sleep interruptible:
sleepq_block(0,0,
Hello,
I've found the following problem, and according to:
http://pubs.opengroup.org/onlinepubs/9699919799/functions/kill.html
(2nd last paragraph of rationale)
It seems like NetBSD should return 0 when killing a zombie process (as
FreeBSD and Linux do).
FreeBSD fixed this in 2004 with the follo
On Tue, Jul 17, 2012 at 09:26:44PM -0400, Matthew Mondor wrote:
> On Tue, 17 Jul 2012 20:54:28 + (UTC)
> mlel...@serpens.de (Michael van Elst) wrote:
>
> > I would also guess that sparse files are very rarely used. But for
> > disk usage purposes you want to consider real disk usage including
19 matches
Mail list logo
