I've run into a bug in the UFS reading code (on Solaris x86 the
major/minor numbers are in 2nd indirect offset not the first), so I've
patched it & bugzilled it
(http://bugzilla.kernel.org/show_bug.cgi?id=3475).
But where do I go from here? There doesn't seem to be a maintainer for
UFS so I can't send it there.
--
Alex Kiernan
On Wed, 13 Oct 2004 12:06:29 +0100, Alex Kiernan <[email protected]> wrote:
> I've run into a bug in the UFS reading code (on Solaris x86 the
> major/minor numbers are in 2nd indirect offset not the first), so I've
> patched it & bugzilled it
> (http://bugzilla.kernel.org/show_bug.cgi?id=3475).
>
> But where do I go from here? There doesn't seem to be a maintainer for
> UFS so I can't send it there.
>
After advice from Alan (thanks), here's the patch which addresses the
problem I'm seeing. Specifically it appears that on x86 Solaris stores
the major/minor device numbers in the 2nd indirect block, not the
first.
--
Alex Kiernan
I've done have done the same with
http://bugzilla.kernel.org/show_bug.cgi?id=3330 and I have the same
question!
Where do I go from now?
Haroldo Gamal
Alex Kiernan wrote:
>I've run into a bug in the UFS reading code (on Solaris x86 the
>major/minor numbers are in 2nd indirect offset not the first), so I've
>patched it & bugzilled it
>(http://bugzilla.kernel.org/show_bug.cgi?id=3475).
>
>But where do I go from here? There doesn't seem to be a maintainer for
>UFS so I can't send it there.
>
>
>
On Wed, Oct 13, 2004 at 01:10:10PM +0100, Alex Kiernan wrote:
> On Wed, 13 Oct 2004 12:06:29 +0100, Alex Kiernan <[email protected]> wrote:
> > I've run into a bug in the UFS reading code (on Solaris x86 the
> > major/minor numbers are in 2nd indirect offset not the first), so I've
> > patched it & bugzilled it
> > (http://bugzilla.kernel.org/show_bug.cgi?id=3475).
> >
> > But where do I go from here? There doesn't seem to be a maintainer for
> > UFS so I can't send it there.
> >
>
> After advice from Alan (thanks), here's the patch which addresses the
> problem I'm seeing. Specifically it appears that on x86 Solaris stores
> the major/minor device numbers in the 2nd indirect block, not the
> first.
1) please, move old_encode_dev()/old_decode_dev() into your helper functions.
2) we could do a bit better now that we have large dev_t. What are complete
rules for
a) Solaris userland dev_t => on-disk data
b) major/minor => Solaris userland dev_t
on sparc and x86 Solaris?
Haroldo Gamal wrote:
> I've done have done the same with
> http://bugzilla.kernel.org/show_bug.cgi?id=3330 and I have the same
> question!
>
> Where do I go from now?
Have you tried contacting the SMBfs maintainer?
from the MAINTAINERS file:
SMB FILESYSTEM
P: Urban Widmark
M: [email protected]
W: http://samba.org/
L: [email protected]
S: Maintained
--
~Randy
I have mailed Mr. Urban Widmark ans answered the appropriate bugzilla
bug - https://bugzilla.samba.org/show_bug.cgi?id=999. No response until now.
Maybe my patches do not apply for some reason, but I've got no response.
I would like to get some feedback.
Randy.Dunlap wrote:
> Haroldo Gamal wrote:
>
>> I've done have done the same with
>> http://bugzilla.kernel.org/show_bug.cgi?id=3330 and I have the same
>> question!
>>
>> Where do I go from now?
>
>
> Have you tried contacting the SMBfs maintainer?
> from the MAINTAINERS file:
>
> SMB FILESYSTEM
> P: Urban Widmark
> M: [email protected]
> W: http://samba.org/
> L: [email protected]
> S: Maintained
>
Haroldo Gamal wrote:
> I have mailed Mr. Urban Widmark ans answered the appropriate bugzilla
> bug - https://bugzilla.samba.org/show_bug.cgi?id=999. No response until
> now.
>
> Maybe my patches do not apply for some reason, but I've got no response.
> I would like to get some feedback.
Hm, if he is unresponsive, you can try any of (in no special order):
a. VFS maintainer (Al Viro)
b. 2.6 maintainer (Andrew Morton)
c. [email protected]
d. [email protected]
> Randy.Dunlap wrote:
>
>> Haroldo Gamal wrote:
>>
>>> I've done have done the same with
>>> http://bugzilla.kernel.org/show_bug.cgi?id=3330 and I have the same
>>> question!
>>>
>>> Where do I go from now?
>>
>>
>>
>> Have you tried contacting the SMBfs maintainer?
>> from the MAINTAINERS file:
>>
>> SMB FILESYSTEM
>> P: Urban Widmark
>> M: [email protected]
>> W: http://samba.org/
>> L: [email protected]
>> S: Maintained
--
~Randy
On Wed, 13 Oct 2004 14:43:51 +0100,
[email protected]
<[email protected]> wrote:
> On Wed, Oct 13, 2004 at 01:10:10PM +0100, Alex Kiernan wrote:
>
>
> > On Wed, 13 Oct 2004 12:06:29 +0100, Alex Kiernan <[email protected]> wrote:
> > > I've run into a bug in the UFS reading code (on Solaris x86 the
> > > major/minor numbers are in 2nd indirect offset not the first), so I've
> > > patched it & bugzilled it
> > > (http://bugzilla.kernel.org/show_bug.cgi?id=3475).
> > >
> > > But where do I go from here? There doesn't seem to be a maintainer for
> > > UFS so I can't send it there.
> > >
> >
> > After advice from Alan (thanks), here's the patch which addresses the
> > problem I'm seeing. Specifically it appears that on x86 Solaris stores
> > the major/minor device numbers in the 2nd indirect block, not the
> > first.
>
> 1) please, move old_encode_dev()/old_decode_dev() into your helper functions.
Will do.
> 2) we could do a bit better now that we have large dev_t. What are complete
> rules for
> a) Solaris userland dev_t => on-disk data
> b) major/minor => Solaris userland dev_t
> on sparc and x86 Solaris?
>
Assuming I've followed it right...
The kernel dev_t has 14 major device bits, 18 minor device bits (with
the major as the most significant bits).
On disk there are 32 bits stored in host byte order, the device is in
the [0] indirect offset on Sparc, [1] on x86.
Looking at an individual entry, if the top 16 bits are clear or
0xffff, then the bottom 16 bits are the device number, with 7 bits of
major (most significant), 8 bits of minor (and the most significant
bit unused). If the top 16 bits are some other pattern, the on disk
mapping is the same as the kernel mapping.
--
Alex Kiernan
On Fri, 15 Oct 2004 17:35:50 +0100, Alex Kiernan <[email protected]> wrote:
> On Wed, 13 Oct 2004 14:43:51 +0100,
> [email protected]
> <[email protected]> wrote:
> > On Wed, Oct 13, 2004 at 01:10:10PM +0100, Alex Kiernan wrote:
> >
> >
> > > On Wed, 13 Oct 2004 12:06:29 +0100, Alex Kiernan <[email protected]> wrote:
> > > > I've run into a bug in the UFS reading code (on Solaris x86 the
> > > > major/minor numbers are in 2nd indirect offset not the first), so I've
> > > > patched it & bugzilled it
> > > > (http://bugzilla.kernel.org/show_bug.cgi?id=3475).
> > > >
> > > > But where do I go from here? There doesn't seem to be a maintainer for
> > > > UFS so I can't send it there.
> > > >
> > >
> > > After advice from Alan (thanks), here's the patch which addresses the
> > > problem I'm seeing. Specifically it appears that on x86 Solaris stores
> > > the major/minor device numbers in the 2nd indirect block, not the
> > > first.
> >
> > 1) please, move old_encode_dev()/old_decode_dev() into your helper functions.
>
> Will do.
>
> > 2) we could do a bit better now that we have large dev_t. What are complete
> > rules for
> > a) Solaris userland dev_t => on-disk data
> > b) major/minor => Solaris userland dev_t
> > on sparc and x86 Solaris?
> >
>
> Assuming I've followed it right...
>
> The kernel dev_t has 14 major device bits, 18 minor device bits (with
> the major as the most significant bits).
>
> On disk there are 32 bits stored in host byte order, the device is in
> the [0] indirect offset on Sparc, [1] on x86.
>
> Looking at an individual entry, if the top 16 bits are clear or
> 0xffff, then the bottom 16 bits are the device number, with 7 bits of
> major (most significant), 8 bits of minor (and the most significant
> bit unused). If the top 16 bits are some other pattern, the on disk
> mapping is the same as the kernel mapping.
>
Attached is code to implement the code move of old_decode_dev and
support for large dev_t (Solaris' own handling of this seems to be
dodgy in the extreme). I've checked Solaris x86/sparc w/ both types of
dev_t encoding for reading. I haven't checked writing as the code to
detect clean filesystems seems to be bust for Solaris UFS filesystems.
I'll have a look at whats wrong w/ it when I've a bit more time.
Because of the different Solaris/Linux large dev encodings, what
should I be doing in get/set inode_dev when the required things won't
fit?
--
Alex Kiernan
On Mon, 18 Oct 2004 11:20:16 +0100, Alex Kiernan <[email protected]> wrote:
> On Fri, 15 Oct 2004 17:35:50 +0100, Alex Kiernan <[email protected]> wrote:
>
>
> > On Wed, 13 Oct 2004 14:43:51 +0100,
> > [email protected]
> > <[email protected]> wrote:
> > > On Wed, Oct 13, 2004 at 01:10:10PM +0100, Alex Kiernan wrote:
> > >
> > >
> > > > On Wed, 13 Oct 2004 12:06:29 +0100, Alex Kiernan <[email protected]> wrote:
> > > > > I've run into a bug in the UFS reading code (on Solaris x86 the
> > > > > major/minor numbers are in 2nd indirect offset not the first), so I've
> > > > > patched it & bugzilled it
> > > > > (http://bugzilla.kernel.org/show_bug.cgi?id=3475).
> > > > >
> > > > > But where do I go from here? There doesn't seem to be a maintainer for
> > > > > UFS so I can't send it there.
> > > > >
> > > >
> > > > After advice from Alan (thanks), here's the patch which addresses the
> > > > problem I'm seeing. Specifically it appears that on x86 Solaris stores
> > > > the major/minor device numbers in the 2nd indirect block, not the
> > > > first.
> > >
> > > 1) please, move old_encode_dev()/old_decode_dev() into your helper functions.
> >
> > Will do.
> >
> > > 2) we could do a bit better now that we have large dev_t. What are complete
> > > rules for
> > > a) Solaris userland dev_t => on-disk data
> > > b) major/minor => Solaris userland dev_t
> > > on sparc and x86 Solaris?
> > >
> >
> > Assuming I've followed it right...
> >
> > The kernel dev_t has 14 major device bits, 18 minor device bits (with
> > the major as the most significant bits).
> >
> > On disk there are 32 bits stored in host byte order, the device is in
> > the [0] indirect offset on Sparc, [1] on x86.
> >
> > Looking at an individual entry, if the top 16 bits are clear or
> > 0xffff, then the bottom 16 bits are the device number, with 7 bits of
> > major (most significant), 8 bits of minor (and the most significant
> > bit unused). If the top 16 bits are some other pattern, the on disk
> > mapping is the same as the kernel mapping.
> >
>
> Attached is code to implement the code move of old_decode_dev and
> support for large dev_t (Solaris' own handling of this seems to be
> dodgy in the extreme). I've checked Solaris x86/sparc w/ both types of
> dev_t encoding for reading. I haven't checked writing as the code to
> detect clean filesystems seems to be bust for Solaris UFS filesystems.
> I'll have a look at whats wrong w/ it when I've a bit more time.
>
The same functionality again:
Fix handling of device inodes on Solaris x86 filesystems, add support
for large dev_t against Solaris UFS filesystems
but with the helper functions moved out of inline code.
--
Alex Kiernan