vfs_ea_tdb

[tridge at tridgell.net]

Jeremy,

 > I don't think it's quite as bad as that. The S3 format is
 > string based, so easily detected by the terminating null.

I think it would have to be a config option. I don't think it would be
sane to have code which says "only 1 byte is 0 and its the last byte,
so its probably not the s4 format" ? That doesn't sound very robust.

Plus the name of the xattr is different in s3 and s4, so we don't need
to guess based on the contents anyway.

 > The S4 format contains a bunch of extra stuff that S3
 > doesn't support or maintain (birth times in NTTIME
 > format etc) so we could cope with both - but I'm expecting
 > the POSIX vendors to add birthtime (as *BSD has) with
 > ns timestamps so we can just use the filesystem for
 > this.

The point is to have one place to store all the information that the
current filesystem you are using doesn't have. If the current
filesystem doesn't have a way to store the alloc_size, then we can
store it here. If it doesn't have a way to store the create time, we
can store it here. 

Some filesystems may get these features over time, but that won't
magically spread to all filesystems on all OSes in any quick
manner. We'll still be dealing with filesystems without these features
in 10 years time.

 > As I recall, both patches were originally done by you, the
 > early S3 one being you did really easy to integrate
 > with existing code (not blaming you here, it's just funny :-).

I thought you'd done it actually - although looking at the history it
goes back much further than I remembered. The main dosmode.c changes
went into cvs in April 2004.

 > All Volker's change is doing I think is storing the
 > S3-specific one in a tdb, we have to map between the
 > two anyway so it doesn't make things any worse than
 > they already are.

right. Though efforts to support both formats in both branches would
be worthwhile.

Cheers, Tridge