Hello.
I sent similar email a few weeks ago but discussion ended without
any useful results if I rememeber well.
Quota in reiserfs is (and needs to be) accounted in bytes not in blocks.
I modified quota system to allow such thing so in kernel there's no
problem. But also 'quotacheck' needs to know how many space does given
file use. Currently it uses st_blocks from stat(2) to compute the space
used but for reiserfs we need precision in bytes, not in 512 byte blocks...
My proposal is to alter stat64() syscall to return also number of bytes
used (I tried to contact Ulrich Drepper <[email protected]> who should
be right person to ask about such things (at least I was said so) but go
no answer...). Does anybody have any better solution?
I know about two others - really ugly ones:
1) fs specific ioctl()
2) compute needed number of bytes from st_size and st_blocks, which is
currently possible but won't be in future
Bye
Honza
On 9 Nov 00 at 19:18, Jan Kara wrote:
> used (I tried to contact Ulrich Drepper <[email protected]> who should
> be right person to ask about such things (at least I was said so) but go
> no answer...). Does anybody have any better solution?
> I know about two others - really ugly ones:
> 1) fs specific ioctl()
> 2) compute needed number of bytes from st_size and st_blocks, which is
> currently possible but won't be in future
If I may, please do not add it into stat/stat64 structure. On Netware,
computing really used space can take eons because of it has to read
allocation tables to memory to find size. It is usually about 500%
slower than retrieving all other file informations.
Or at least add some parameter to stat so that filesystem can say which
informations are important for you. But I think that ioctl is less
ugly. But that's just my opinion and I know that others here are strongly
against ioctl.
Best regards,
Petr Vandrovec
[email protected]
Followup to: <[email protected]>
By author: Jan Kara <[email protected]>
In newsgroup: linux.dev.kernel
>
> Hello.
>
> I sent similar email a few weeks ago but discussion ended without
> any useful results if I rememeber well.
>
> Quota in reiserfs is (and needs to be) accounted in bytes not in blocks.
> I modified quota system to allow such thing so in kernel there's no
> problem. But also 'quotacheck' needs to know how many space does given
> file use. Currently it uses st_blocks from stat(2) to compute the space
> used but for reiserfs we need precision in bytes, not in 512 byte blocks...
> My proposal is to alter stat64() syscall to return also number of bytes
> used (I tried to contact Ulrich Drepper <[email protected]> who should
> be right person to ask about such things (at least I was said so) but go
> no answer...). Does anybody have any better solution?
> I know about two others - really ugly ones:
> 1) fs specific ioctl()
> 2) compute needed number of bytes from st_size and st_blocks, which is
> currently possible but won't be in future
>
Report a block size (really allocation unit size) st_blocks == 1?
-hpa
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
In article <[email protected]>,
H. Peter Anvin <[email protected]> wrote:
>Report a block size (really allocation unit size) st_blocks == 1?
If you mean st_blksize, well:
The value st_blocks gives the size of the file in 512-byte
blocks. The value st_blksize gives the "preferred" block?
size for efficient file system I/O. (Writing to a file in
smaller chunks may cause an inefficient read-modify-
rewrite.)
Telling programs 'please use 1-byte r/w buffers' is probably
a bad idea.
Mike.
--
People get the operating system they deserve.
Hello.
> On 9 Nov 00 at 19:18, Jan Kara wrote:
> > used (I tried to contact Ulrich Drepper <[email protected]> who should
> > be right person to ask about such things (at least I was said so) but go
> > no answer...). Does anybody have any better solution?
> > I know about two others - really ugly ones:
> > 1) fs specific ioctl()
> > 2) compute needed number of bytes from st_size and st_blocks, which is
> > currently possible but won't be in future
>
> If I may, please do not add it into stat/stat64 structure. On Netware,
> computing really used space can take eons because of it has to read
> allocation tables to memory to find size. It is usually about 500%
> slower than retrieving all other file informations.
And how do you fill in st_blocks field?
Honza
On 14 Nov 00 at 18:39, Jan Kara wrote:
> Hello.
>
> > On 9 Nov 00 at 19:18, Jan Kara wrote:
> > > used (I tried to contact Ulrich Drepper <[email protected]> who should
> > > be right person to ask about such things (at least I was said so) but go
> > > no answer...). Does anybody have any better solution?
> > > I know about two others - really ugly ones:
> > > 1) fs specific ioctl()
> > > 2) compute needed number of bytes from st_size and st_blocks, which is
> > > currently possible but won't be in future
> >
> > If I may, please do not add it into stat/stat64 structure. On Netware,
> > computing really used space can take eons because of it has to read
> > allocation tables to memory to find size. It is usually about 500%
> > slower than retrieving all other file informations.
> And how do you fill in st_blocks field?
Currently as st_size / st_blksize. If I'll want to report real used size,
so that quotas could be built on the top of Netware space restrictions,
Netware is willing to return size in its allocation blocks after holes
and compression takes place, but while computation time is afforable for
open(), it is not for stat()ing thousands of entries in directories.
Best regards,
Petr Vandrovec
[email protected]
> On 14 Nov 00 at 18:39, Jan Kara wrote:
> > Hello.
> >
> > > On 9 Nov 00 at 19:18, Jan Kara wrote:
> > > > used (I tried to contact Ulrich Drepper <[email protected]> who should
> > > > be right person to ask about such things (at least I was said so) but go
> > > > no answer...). Does anybody have any better solution?
> > > > I know about two others - really ugly ones:
> > > > 1) fs specific ioctl()
> > > > 2) compute needed number of bytes from st_size and st_blocks, which is
> > > > currently possible but won't be in future
> > >
> > > If I may, please do not add it into stat/stat64 structure. On Netware,
> > > computing really used space can take eons because of it has to read
> > > allocation tables to memory to find size. It is usually about 500%
> > > slower than retrieving all other file informations.
> > And how do you fill in st_blocks field?
>
> Currently as st_size / st_blksize. If I'll want to report real used size,
> so that quotas could be built on the top of Netware space restrictions,
> Netware is willing to return size in its allocation blocks after holes
> and compression takes place, but while computation time is afforable for
> open(), it is not for stat()ing thousands of entries in directories.
Hmm.. But that's problem as 'quotacheck' uses stat to get space used by
file... So it won't work on Netware anyway.
Honza
Off topic for lkml, I know. But since software
patents could have a huge impact on open source,
UK residents on this list should be aware that
the UK patent office is currently asking for
comments on changes to the patent law regarding
software and business patents.
>From their page:
"Should Patents be Granted for Computer Software or
Ways of Doing Business?"
"We want to know what you think about this so that
Government policy is evidence-based and relevant to
business, commerce, and consumers - in other words
to you. So, whether you are in the software industry,
financial services, are a software user, a consumer,
or are otherwise interested, we want to hear from you."
http://www.patent.gov.uk/snews/notices/softcons.html
news://discuss.patent.gov.uk/patentoffice.softpat
--
LarsG