lkml.org 
[lkml]   [2018]   [Oct]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH v2 6/5] statx: add STATX_RESULT_MASK flag
Date
Miklos Szeredi <miklos@szeredi.hu> wrote:

> This is very much about the basic statx fields. I.e. what does
> result_mask == STATX_BASIC_STATS means?
>
> a) this is a legacy stat() implementation that doesn't fill in the
> result_mask properly
>
> b) this is an up-todate stat() implementation that does fill the
> result_mask properly and all fields are valid
>
> There's no way to tell which one it is, and no way to request that
> filesystem try b) even if it's more costly.

Okay, I think I see what you're getting at. We need to be able to tell the
user that we don't actually know what's good and what's not. I guess this
doesn't only apply to fuse, but could also apply to nfs potentially as nfs
doesn't necessarily know what the server is capable of and where it's making
stuff up (imagine an NFS server backing both an ext4 and a fat filesystem).

I would be tempted to represent this with an attribute flag instead, say:

STATX_ATTR_UNCERTAIN_VALUES

Your attributes are actually in one of at least three states, not two:
unsupported, definite and uncertain. Definite things might include such as
STATX_TYPE - after all, if you don't know what type a file is, you can't
really use it.

If someone really needs to know, it might be worth deferring further
information to fsinfo().

David

\
 
 \ /
  Last update: 2018-10-20 01:51    [W:0.074 / U:4.360 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site