lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Fri, 27 Apr 2012 10:39:05 +0100
From:	David Howells <dhowells@...hat.com>
To:	Dave Chinner <david@...morbit.com>
Cc:	dhowells@...hat.com, linux-fsdevel@...r.kernel.org,
	linux-nfs@...r.kernel.org, linux-cifs@...r.kernel.org,
	samba-technical@...ts.samba.org, linux-ext4@...r.kernel.org,
	wine-devel@...ehq.org, kfm-devel@....org, nautilus-list@...me.org,
	linux-api@...r.kernel.org, libc-alpha@...rceware.org
Subject: Re: [PATCH 0/6] Extended file stat system call

Dave Chinner <david@...morbit.com> wrote:

> If we are adding per-inode flags, then what do we do with filesystem specific
> flags? e.g. XFS has quite a number of per-inode flags that don't align with
> any other filesystem (e.g. filestream allocator, real time file, behaviour
> inheritence flags, etc), but may be useful to retrieve in such a call. We
> currently have an ioctl to get that information from each inode. Have you
> thought about how to handle such flags?

I haven't looked at XFS with regard to xstat as yet, so I'm not sure exactly
which flags you're talking about.  The question, though, is what will actually
make use of these flags?  Will it just be XFS tools or are they something that
a GUI might make use of?

Either you can add some of them to the ioc flags (which may be impractical, I
grant you) or we'd have to add an arbitrary fs-type specific field and specify
the host fs (the provision of which might not be a bad idea in and of itself)
to tell userspace how to interpret them.

> Along the same lines, filesytsems can have different allocation constraints
> to IO the filesystem block size - ext4 with it's bigalloc hack, XFS with it's
> per-inode extent size hints and the realtime device, etc. Then there's
> optimal IO characteristics (e.g. geometery hints like stripe unit/stripe
> width for the allocation policy of that given file) that applications could
> use if they were present rather than having to expose them through ioctls
> that nobody even knows about...

Yeah...  Not representable by one number.  You'd have to unset a flag to say
you were providing this information.

However, providing a whole bunch of hints about I/O characteristics is probably
beyond this syscall - especially if it isn't constant over the length of a
file.  That's specialist knowledge that most applications don't need to know.
Having a generic way to retrieve it, though, may be a good idea.

OTOH, there's plenty of uncommitted space, so if we can condense the hints down
to something small, we could perhaps add it later - but from your paragraph
above, it doesn't sound like it'll be small.

> Perhaps also exposing the project ID for quota purposes, like we do UID and
> GID. That way we wouldn't need a filesystem specific ioctl to read it....

Is this an XFS only thing?  If so, can it be generalised?

David
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists