Re: Used space in bytes

Re: Used space in bytes

[Petr Vandrovec]

On  9 Nov 00 at 19:18, Jan Kara wrote:
> used (I tried to contact Ulrich Drepper <drepper@redhat.com> 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
                                                        vandrove@vc.cvut.cz

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Used space in bytes

[Jan Kara]

  Hello.

> On  9 Nov 00 at 19:18, Jan Kara wrote:
> > used (I tried to contact Ulrich Drepper <drepper@redhat.com> 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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

[Off topic] UK patent office wants comments on software patent laws.

[Lars Gaarden]

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Used space in bytes

[Petr Vandrovec]

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 <drepper@redhat.com> 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
                                                      vandrove@vc.cvut.cz
                                                      
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Used space in bytes

[Jan Kara]

> 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 <drepper@redhat.com> 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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Used space in bytes

[Miquel van Smoorenburg]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 773 bytes --]

In article <8uf21i$ro7$1@cesium.transmeta.com>,
H. Peter Anvin <hpa@zytor.com> 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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Used space in bytes

[H. Peter Anvin]

Followup to:  <20001109191843.B11373@atrey.karlin.mff.cuni.cz>
By author:    Jan Kara <jack@suse.cz>
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 <drepper@redhat.com> 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
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Used space in bytes

[Jan Kara]

  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 <drepper@redhat.com> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/