[PATCH] libvolume_id fixes for solaris

Kay Sievers kay.sievers at vrfy.org
Tue Mar 7 12:51:52 PST 2006

On Tue, Mar 07, 2006 at 10:16:27AM -0800, Artem Kachitchkine wrote:
> With the -v option, it will print a boatload of additional information:
> # fstyp -v /dev/dsk/c0d0s0
> ufs
> magic   11954   format  dynamic time    Tue Mar  7 02:17:14 2006
> sblkno  16      cblkno  24      iblkno  32      dblkno  824
> sbsize  2048    cgsize  8192    cgoffset 32     cgmask  0xffffffc0
> ncg     1491    size    78138144        blocks  76933376
> bsize   8192    shift   13      mask    0xffffe000
> fsize   1024    shift   10      mask    0xfffffc00
> frag    8       shift   3       fsbtodb 1
> minfree 1%      maxbpg  2048    optim   time
> ...
> What I might end up doing, is add another option that will print something 
> vol_id in Solaris.

Can you get Label/uuid that way too?

> libvolume_id tells me about filesystems my OS doesn't support: that's 
> pretty cool for diagnosis and stuff, but I guess most people only care if 
> they can mount a filesystem or not.

Yeah, they probably care only about that, but sometimes it's nice to
know what exactly you can't do. :)

> Going back to your iPod example: why 
> would any application would support iPods with FAT and not with HFS or 
> XYZFS, as long as the OS can mount it and there is valid data in 
> .iPod_Control? The only ones outside HAL who care about fs type are 
> sysadmins and fs management tools.

As for the HFS iPod, seems we can't reliably write to it so, the audio
player wants to figure out if it's a fat formatted one and it's safe to
write to it. Not a big issue, it's just that we need to be aware of
cases where applications already depend on such values ...


More information about the hal mailing list