All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Chaloupka <jchaloup-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
To: mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
Cc: schwab-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
	linux-man <linux-man-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org>,
	Alexander Viro
	<viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org>
Subject: Re: [PATCH] statfs.2 does not describe f_flag field
Date: Wed, 04 Feb 2015 14:01:19 +0100	[thread overview]
Message-ID: <54D2181F.9070300@redhat.com> (raw)
In-Reply-To: <CAKgNAkg19+w1O2JOKNEFziy8d3KvsWvQUr1PSpiM1Fk9818yig-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>


On 02/04/2015 12:51 PM, Michael Kerrisk (man-pages) wrote:
> Hi Jan,
>
> On 4 February 2015 at 09:48, Jan Chaloupka <jchaloup-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
>> Based on kernel commit [1], new flag f_flag is added to statfs struct.
>>
>> Before kernel 2.6.36, glibc's statvfs.f_flags was computed be iterating
>> through all mounted points. This was inefficient and could cause a delay.
>> Since kernel 2.6.36, statfs struct has new field f_flag, which already
>> extracts mount options without iterating through mount point.
>> statfs.f_flag flags of glibc and kernel are the same (plus kernel adds
>> additional flag ST_VALID used only internally). So no matter what version
>> of kernel is used, flags does not change.
>>
>> Flags used in statfs.f_flags can be enumerated from upstreams's
>> glibc/internal_statvfs.c, lines 155-173. Nine flags in sum:
>>
>> ST_RDONLY = 1
>> ST_NOSUID = 2
>> ST_NODEV = 4
>> ST_NOEXEC = 8
>> ST_SYNCHRONOUS = 16
>> ST_MANDLOCK = 64
>> ST_NOATIME = 1024
>> ST_NODIRATIME = 2048
>> ST_RELATIME = 4096
>>
>> This patch describes missing flag.
>>
>> [1] https://github.com/torvalds/linux/commit/365b18189789bfa1acd9939e6312b8a4b4577b28
> Thanks for the heads up. But this patch is a bit muddled, since it
> mixes details about statfs(2) and statvfs(3).

Yes. As kernel copied all the flags, it is now duplicated. But you are 
right it more suites for statvfs(2).

>   I've instead made some more detailed changes for the statfs(2) and statvfs(2) pages.
>

Thanks.

>
> Thanks,
>
> Michael
>
>
>> Signed-off-by: Jan Chaloupka <jchaloup-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>> ---
>>   man2/statfs.2 |   28 +++++++++++++++++++++++++++-
>>   1 file changed, 27 insertions(+), 1 deletion(-)
>>
>> diff --git a/man2/statfs.2 b/man2/statfs.2
>> index 714bc7c..46cfa5f 100644
>> --- a/man2/statfs.2
>> +++ b/man2/statfs.2
>> @@ -65,7 +65,9 @@ struct statfs {
>>       fsid_t       f_fsid;    /* filesystem id */
>>       __SWORD_TYPE f_namelen; /* maximum length of filenames */
>>       __SWORD_TYPE f_frsize;  /* fragment size (since Linux 2.6) */
>> -    __SWORD_TYPE f_spare[5];
>> +    __SWORD_TYPE f_flags;   /* mount flags of filesystem
>> +                               (since Linux 2.6.36) */
>> +    __SWORD_TYPE f_spare[4];
>>   };
>>
>>   Filesystem types:
>> @@ -146,6 +148,30 @@ Most of these MAGIC constants are defined in
>>   .IR /usr/include/linux/magic.h ,
>>   and some are hardcoded in kernel sources.
>>   .PP
>> +Mount flags of
>> +.I f_flags
>> +field are extracted from an option string of a mount point defined in
>> +.BR mount (8).
>> +The field can be combination of the following flags
>> +(corresponding mount options are in the right column):
>> +.in
>> +.nf
>> +
>> +   ST_RDONLY          ro
>> +   ST_NOSUID          nosuid
>> +   ST_NOEXEC          noexec
>> +   ST_NODEV           nodev
>> +   ST_SYNCHRONOUS     sync
>> +   ST_MANDLOCK        mand
>> +   ST_NOATIME         noatime
>> +   ST_NODIRATIME      nodiratime
>> +   ST_RELATIME        relatime
>> +
>> +.fi
>> +.in
>> +For kernel less than 2.6.36 option flags are extracted by iterating
>> +through individual mount points which can be inefficient and cause delay.
>> +.PP
>>   Nobody knows what
>>   .I f_fsid
>>   is supposed to contain (but see below).
>>
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

      parent reply	other threads:[~2015-02-04 13:01 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-04  8:48 [PATCH] statfs.2 does not describe f_flag field Jan Chaloupka
     [not found] ` <20150204084843.29485.58701.stgit-/v0jm+aXwyk2pP1PFFXgSPXAX3CI6PSWQQ4Iyu8u01E@public.gmane.org>
2015-02-04 11:51   ` Michael Kerrisk (man-pages)
     [not found]     ` <CAKgNAkg19+w1O2JOKNEFziy8d3KvsWvQUr1PSpiM1Fk9818yig-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-02-04 13:01       ` Jan Chaloupka [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=54D2181F.9070300@redhat.com \
    --to=jchaloup-h+wxahxf7alqt0dzr+alfa@public.gmane.org \
    --cc=hch-jcswGhMUV9g@public.gmane.org \
    --cc=linux-man-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=schwab-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
    --cc=viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.