On Sat, Sep 10, 2016 at 10:00:29AM +1000, Dave Chinner wrote: > On Thu, Sep 08, 2016 at 11:07:16PM -0700, Darrick J. Wong wrote: > > On Fri, Sep 09, 2016 at 09:38:06AM +1000, Dave Chinner wrote: > > > On Tue, Aug 30, 2016 at 12:09:49PM -0700, Darrick J. Wong wrote: > > > > > I recall for FIEMAP that some filesystems may not have files aligned > > > > > to sector offsets, and we just used byte offsets. Storage like > > > > > NVDIMMs are cacheline granular, so I don't think it makes sense to > > > > > tie this to old disk sector sizes. Alternately, the units could be > > > > > in terms of fs blocks as returned by statvfs.st_bsize, but mixing > > > > > units for fmv_block, fmv_offset, fmv_length is uneeded complexity. > > > > > > > > Ugh. I'd rather just change the units to bytes rather than force all > > > > the users to multiply things. :) > > > > > > Yup, units need to be either in disk addresses (i.e. 512 byte units) > > > or bytes. If people can't handle disk addresses (seems to be the > > > case), the bytes it should be. > > > > <nod> > > > > > > I'd much rather just add more special owner codes for any other > > > > filesystem that has distinguishable metadata types that are not > > > > covered by the existing OWN_ codes. We /do/ have 2^64 possible > > > > values, so it's not like we're going to run out. > > > > > > This is diagnositc information as much as anything, just like > > > fiemap is diagnostic information. So if we have specific type > > > information, it needs to be reported accurately to be useful. > > > > > > Hence I really don't care if the users and developers of other fs > > > types don't understand what the special owner codes that a specific > > > filesystem returns mean. i.e. it's not useful user information - > > > only a tool that groks the specific filesystem is going to be able > > > to anything useful with special owner codes. So, IMO, there's little > > > point trying to make them generic or to even trying to define and > > > explain them in the man page.... > > > > <shrug> I'm ok with describing generally what each special owner code > > means. Maybe the manpage could be more explicit about "None of these > > codes are useful unless you're a low level filesystem tool"? > > You can add that, but it doesn't address the underlying problem. > i.e. that we can add/change the codes, their name, meaning, etc, > and now there's a third party man page that is incorrect and out of > date. It's the same problem with documenting filesystem specific > mount options in mount(8). Better, IMO, is to simple say "refer to > filesystem specific documentation for a description of these special > values". e.g. refer them to the XFS Filesystem Structure > document where this is all spelled out in enough detail to be useful > for someone thinking that they might want to use them.... We could simply put a manpage in the xfsprogs source documenting the XFS owner codes and let other implementers make their own manpage with a discussion of the owner codes (and whatever other quirks they have). Sort of fragments things, but that's probably unavoidable. :) --D > > Cheers, > > Dave. > -- > Dave Chinner > david@xxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
