Re: quotactl issues [Solved]
On Fri, Apr 12, 2002 at 08:15:49AM -0500, mark tinguely wrote: > > I tried to replicate the problem with DDB and QUOTA compiled into the kernel > but could not. Built a test system, ran a bunch of gdb sessions & found the problem. Despite having this: > grep quota /etc/rc.conf enable_quotas="YES" # turn on quotas on startup (or NO). check_quotas="YES" # Check quotas on startup (or NO). Somehow quotas were off on the filesystem in question. I would suggest the following change to the man page for quotactl: [EINVAL] Cmd or the command type is invalid. Q_GETQUOTA returns EINVAL if quotas are not currently enabled for this filesystem. /\/\ \/\/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: quotactl issues
> > > No replies on this. Nobody has any ideas? > > > > Nobody has seen it until now. > > SOMEbody did - that's why they hacked edquota.c! See code fragment below. I tried to replicate the problem with DDB and QUOTA compiled into the kernel but could not. Grasping at straws, I am wondering if he has some kind of corruption in the quota file. But even corruption in the quota file should not make quotactl() return a EINVAL (besides the documented bad command, or type, that would be from a low driver with a bad unit number). Since this is not generically reproducable, could you add DDB to the kernel and trace a run through the quoactl() routine to see why the EINVAL is generated? --mark tinguely To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: quotactl issues
John Baldwin wrote: > > Note the warnx() call. It writes directly to the quota file so you can > > set quotas even if your current kernel is not capable of enforcing > > them. Is your kernel compiled with "options QUOTA"? I can tell you on > > all my 4.* systems (4.0 through 4.5) edquota calls quotactl and it > > succeeds: > > > > 90883 edquota CALL quotactl(0x8057828,0x4,0x3e8,0x8057808) > > 90883 edquota NAMI "/usr" > > 90883 edquota RET quotactl 0 > > He didn't get EOPNOTSUPP, he got EINVAL. Perhaps it is a bug in edquota > to edit the quota file directly for an errno other than EOPNOTSUPP? "edquota" tries to do for quotas what vipw does for password entries. The file you edit is not the real "quota file", but a temp copy. For all practical purposes, you don't modify a quota until you have issued a successful "quotactl" call to set the new quota (or delete it). What's happening is expected: it's just like pwd_mkdb failing after editing the password file with vipw. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: quotactl issues
On 11-Apr-2002 Dan Nelson wrote:
> In the last episode (Apr 11), Michael R. Wayne said:
>> Now - to re-iterate my point. The code for edquota FAILS IN EXACTLY
>> THE SAME WAY with EINVAL. But edquota IGNORES this error. The
>> reason that edquota works is that, when it gets this failure, it
>> reads and writes the quota file directly. If quotactl works
>> properly, why is there code in edquota.c to read/write the quotactl
>> file directly?
>>
>> /usr/src/usr.sbin/edquota/edquota.c
>>
>> if (quotactl(fs->fs_file, qcmd, id, &qup->dqblk) != 0) {
>> if (errno == EOPNOTSUPP && !warned) { <--- running
through gdb errno is
>> EINVAL here.
>> warned++;
>> warnx("warning: quotas are not compiled into this kernel");
>> sleep(3);
>> }
>> if ((fd = open(qfpathname, O_RDONLY)) < 0) {<--- So,
edquota ignores
>> quotactl and does it manually
>
> Note the warnx() call. It writes directly to the quota file so you can
> set quotas even if your current kernel is not capable of enforcing
> them. Is your kernel compiled with "options QUOTA"? I can tell you on
> all my 4.* systems (4.0 through 4.5) edquota calls quotactl and it
> succeeds:
>
> 90883 edquota CALL quotactl(0x8057828,0x4,0x3e8,0x8057808)
> 90883 edquota NAMI "/usr"
> 90883 edquota RET quotactl 0
He didn't get EOPNOTSUPP, he got EINVAL. Perhaps it is a bug in edquota
to edit the quota file directly for an errno other than EOPNOTSUPP?
--
John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: quotactl issues
In the last episode (Apr 11), Michael R. Wayne said:
> Now - to re-iterate my point. The code for edquota FAILS IN EXACTLY
> THE SAME WAY with EINVAL. But edquota IGNORES this error. The
> reason that edquota works is that, when it gets this failure, it
> reads and writes the quota file directly. If quotactl works
> properly, why is there code in edquota.c to read/write the quotactl
> file directly?
>
> /usr/src/usr.sbin/edquota/edquota.c
>
> if (quotactl(fs->fs_file, qcmd, id, &qup->dqblk) != 0) {
> if (errno == EOPNOTSUPP && !warned) { <--- running through
>gdb errno is EINVAL here.
> warned++;
> warnx("warning: quotas are not compiled into this kernel");
> sleep(3);
> }
> if ((fd = open(qfpathname, O_RDONLY)) < 0) {<--- So, edquota
>ignores quotactl and does it manually
Note the warnx() call. It writes directly to the quota file so you can
set quotas even if your current kernel is not capable of enforcing
them. Is your kernel compiled with "options QUOTA"? I can tell you on
all my 4.* systems (4.0 through 4.5) edquota calls quotactl and it
succeeds:
90883 edquota CALL quotactl(0x8057828,0x4,0x3e8,0x8057808)
90883 edquota NAMI "/usr"
90883 edquota RET quotactl 0
--
Dan Nelson
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: quotactl issues
On Thu, Apr 11, 2002 at 01:48:40PM -0700, Terry Lambert wrote:
> "Michael R. Wayne" wrote:
> > No replies on this. Nobody has any ideas?
>
> Nobody has seen it until now.
SOMEbody did - that's why they hacked edquota.c! See code fragment below.
> > On Wed, Apr 10, 2002 at 01:33:21PM -0400, Michael R. Wayne wrote:
> > > Ported some code that uses quotactl to 4.3 p19 and it fails with EINVAL
> > > when trying to:
> > >quotactl("var/mail", QCMD(Q_GETQUOTA, USRQUOTA), VALID_UID, &blk)
> > > Looked at the source for edquota on 4.5 RELEASE (what I had handy),
> > > and ran a copy of it through gdb, it fails with the same error,
> > > then it goes in and reads/writes the quota files directly!
> > >
> > > So, is quotactl just not supported or do the filesystems need to
> > > be converted or what?
>
> 1)Path should be absolute
It is in the code. I messed up in the email post.
> 2)Path *must* refer to a mount point; you look like you are
> treating quotas as if they are more granular than they are.
> Quotas are on a per FS basis *only*.
/var/mail is a mount point on this box.
> 3)Setting a manifest "VALID_UID" doesn't make it valid, just
> because you name it that. 8-).
OK, I am using 1017 and 1017 is a valid user id on the system. I
abstracted in the email.
> 4)"[EINVAL] Cmd or the command type is invalid."
Right. But the same code works on other BSD systems.
> 5)Are you sure that quotas are enables on this FS already?
Yes. And edquota (sorta, see below) works OK.
> 6)Are you sure blk is a struct dqblk?
Yes.
> 7)Quota UID and GID ranges are more limited than FreeBSD
> otherwise limits UID/GID ranges. Make sure that "VALID_UID"
> isn't larger than 65535 or smaller than 0.
1017, which is a valid userid.
Now - to re-iterate my point. The code for edquota FAILS IN EXACTLY
THE SAME WAY with EINVAL. But edquota IGNORES this error. The
reason that edquota works is that, when it gets this failure, it
reads and writes the quota file directly. If quotactl works
properly, why is there code in edquota.c to read/write the quotactl
file directly?
/usr/src/usr.sbin/edquota/edquota.c
if (quotactl(fs->fs_file, qcmd, id, &qup->dqblk) != 0) {
if (errno == EOPNOTSUPP && !warned) { <--- running through
gdb errno is EINVAL here.
warned++;
warnx("warning: quotas are not compiled into this kernel");
sleep(3);
}
if ((fd = open(qfpathname, O_RDONLY)) < 0) {<--- So, edquota
ignores quotactl and does it manually
fd = open(qfpathname, O_RDWR|O_CREAT, 0640);
if (fd < 0 && errno != ENOENT) {
warn("%s", qfpathname);
free(qup);
continue;
}
warnx("creating quota file %s", qfpathname);
sleep(3);
(void) fchown(fd, getuid(),
getentry(quotagroup, GRPQUOTA));
(void) fchmod(fd, 0640);
}
lseek(fd, (long)(id * sizeof(struct dqblk)), L_SET);
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: quotactl issues
"Michael R. Wayne" wrote:
> No replies on this. Nobody has any ideas?
Nobody has seen it until now.
> On Wed, Apr 10, 2002 at 01:33:21PM -0400, Michael R. Wayne wrote:
> > Ported some code that uses quotactl to 4.3 p19 and it fails with EINVAL
> > when trying to:
> >quotactl("var/mail", QCMD(Q_GETQUOTA, USRQUOTA), VALID_UID, &blk)
> > Looked at the source for edquota on 4.5 RELEASE (what I had handy),
> > and ran a copy of it through gdb, it fails with the same error,
> > then it goes in and reads/writes the quota files directly!
> >
> > So, is quotactl just not supported or do the filesystems need to
> > be converted or what?
1) Path should be absolute
2) Path *must* refer to a mount point; you look like you are
treating quotas as if they are more granular than they are.
Quotas are on a per FS basis *only*.
3) Setting a manifest "VALID_UID" doesn't make it valid, just
because you name it that. 8-).
4) "[EINVAL] Cmd or the command type is invalid."
5) Are you sure that quotas are enables on this FS already?
6) Are you sure blk is a struct dqblk?
7) Quota UID and GID ranges are more limited than FreeBSD
otherwise limits UID/GID ranges. Make sure that "VALID_UID"
isn't larger than 65535 or smaller than 0.
-- Terry
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: quotactl issues
In the last episode (Apr 11), Michael R. Wayne said:
> No replies on this. Nobody has any ideas?
>
> /\/\ \/\/
>
> On Wed, Apr 10, 2002 at 01:33:21PM -0400, Michael R. Wayne wrote:
> >
> > Ported some code that uses quotactl to 4.3 p19 and it fails with EINVAL
> > when trying to:
> >quotactl("var/mail", QCMD(Q_GETQUOTA, USRQUOTA), VALID_UID, &blk)
> > Looked at the source for edquota on 4.5 RELEASE (what I had handy),
> > and ran a copy of it through gdb, it fails with the same error,
> > then it goes in and reads/writes the quota files directly!
> >
> > So, is quotactl just not supported or do the filesystems need to
> > be converted or what?
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
Do you have "options QUOTA" in yur kernel config file?
--
Dan Nelson
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: quotactl issues
No replies on this. Nobody has any ideas?
/\/\ \/\/
On Wed, Apr 10, 2002 at 01:33:21PM -0400, Michael R. Wayne wrote:
>
> Ported some code that uses quotactl to 4.3 p19 and it fails with EINVAL
> when trying to:
>quotactl("var/mail", QCMD(Q_GETQUOTA, USRQUOTA), VALID_UID, &blk)
> Looked at the source for edquota on 4.5 RELEASE (what I had handy),
> and ran a copy of it through gdb, it fails with the same error,
> then it goes in and reads/writes the quota files directly!
>
> So, is quotactl just not supported or do the filesystems need to
> be converted or what?
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
quotactl issues
Ported some code that uses quotactl to 4.3 p19 and it fails with EINVAL
when trying to:
quotactl("var/mail", QCMD(Q_GETQUOTA, USRQUOTA), VALID_UID, &blk)
Looked at the source for edquota on 4.5 RELEASE (what I had handy),
and ran a copy of it through gdb, it fails with the same error,
then it goes in and reads/writes the quota files directly!
So, is quotactl just not supported or do the filesystems need to
be converted or what?
/\/\ \/\/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
