Re: [tlug] Ubuntu 13.10 clock problems (was: Ibus and Ubuntu based)

["Stephen J. Turnbull" <stephen@example.com>]

Bruno Raoult writes:

 > On Mon, Nov 18, 2013 at 8:46 AM, Stephen J. Turnbull <stephen@example.com> wrote:
 >> Benjamin Tayehanpour writes:

 >>> Gah. Is there a file-system equivalent of the OSI model?

 >> The POSIX standard itself, I guess.
                                                   
 > I am not sure. Posix is about interfaces (API, commands...), not
 > about underlying implementation.

Just like OSI.  It's possible to implement OSI on top of TCP/IP (well,
some of it comes at lowers levels), but it's not very efficient.

 > A file system could have different layout, and expose a POSIX api,
 > which would show standardized information.

That's not good enough.  POSIX requires semantics of the operations, as
well.  I don't know enough about the file system aspects to give good
simple examples, but here are two, one very simple and one file-system
related:

1.  rename(2) (the function that implements "mv") is atomic.

2.  open(2) is atomic, in the sense that part of a file cannot be
open(2)'ed.  This bites caching network filesystems such as Coda, which
can provide POSIX semantics for open(2), at the expense of a *long*
delay before *any* of the file is available to read(2) -- for video
files it can take many seconds while the file is being copied across the
network before the playback can begin.  This isn't true of protocols
like NFS, but they don't qualify as POSIX file systems because they fail
in other respects.

 > There is no such "Posix file system". And there is no "inode" concept
 > in Posix, an inode being part of implementation (generally
 > *ix). Posix wants a file system to have a minimal set of information
 > (generally inspired from the Unix world, therefore from a usual inode
 > structure). It does not mean an inode must exist.

Who said inodes must exist?  I just said that if he wants a model
(layered APIs plus semantics defined in terms of concepts at the
current level of abstraction) for file systems that break them down
according to levels of abstraction, POSIX probably provides one.  True,
POSIX's layers of abstraction probably aren't a good fit for NTFS, but
then neither are OSI's a perfect fit for TCP/IP.

 > For instance, NTFS does not have "real" inodes (MFT is similar to
 > inode in terms of role, but is not).

And NTFS, like Coda, fails to present efficient POSIX semantics in many
cases.  It does other things better, of course, but there are cases
where trying to use NTFS in POSIX mode will cost you customers.

 > But this is just a vocabulary issue: If we agree on "inode" being a
 > place where file information (metadata) is stored, this would be OK.

No, I don't think that's satisfactory.  As you say, inode is a
particular implementation that brings along some semantic baggage, and 
it would not give Benjamin the precision he wants.