[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 ...
Thanks,
Kay
More information about the hal
mailing list