gpart/gstripe problems?
I have:
sf-03 gpart show
= 34 976773101 ada0 GPT (466G)
34128 1 freebsd-boot (64K)
1624194304 2 freebsd-ufs (2.0G)
4194466 100663296 3 freebsd-swap (48G)
104857762 871915373 4 freebsd (416G)
= 34 976773101 ada1 GPT (466G)
34128 1 freebsd-boot (64K)
1624194304 2 freebsd-ufs (2.0G)
4194466 100663296 3 freebsd-swap (48G)
104857762 871915373 4 freebsd (416G)
sf-03 ls -ls /dev/ada*
0 crw-r- 1 root operator0, 78 Jan 18 14:35 /dev/ada0
0 crw-r- 1 root operator0, 80 Jan 18 14:35 /dev/ada0p1
0 crw-r- 1 root operator0, 81 Jan 18 14:35 /dev/ada0p2
0 crw-r- 1 root operator0, 82 Jan 18 14:35 /dev/ada0p3
0 crw-r- 1 root operator0, 83 Jan 18 14:35 /dev/ada0s4
0 crw-r- 1 root operator0, 79 Jan 18 14:35 /dev/ada1
0 crw-r- 1 root operator0, 84 Jan 18 14:35 /dev/ada1p1
0 crw-r- 1 root operator0, 85 Jan 18 14:35 /dev/ada1p2
0 crw-r- 1 root operator0, 86 Jan 18 14:35 /dev/ada1p3
0 crw-r- 1 root operator0, 87 Jan 18 14:35 /dev/ada1s4
next I did:
# gstripe label s0 /dev/ada{0,1}s4
and on the console the following appeared:
GEOM_STRIPE: Device s0 activated.
GEOM_STRIPE: Cannot add disk gptid/bd0f6e54-22ea-11e0-b27c-001b245d5a5b to s0
(error=17).
GEOM_STRIPE: Cannot add disk gptid/bdf7d563-22ea-11e0-b27c-001b245d5a5b to s0
(error=17).
is this realy an error?
cheers,
danny
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: gpart/gstripe problems?
On 18.1.2011 16:48, Daniel Braniss wrote:
I have:
sf-03 gpart show
= 34 976773101 ada0 GPT (466G)
34128 1 freebsd-boot (64K)
1624194304 2 freebsd-ufs (2.0G)
4194466 100663296 3 freebsd-swap (48G)
104857762 871915373 4 freebsd (416G)
= 34 976773101 ada1 GPT (466G)
34128 1 freebsd-boot (64K)
1624194304 2 freebsd-ufs (2.0G)
4194466 100663296 3 freebsd-swap (48G)
104857762 871915373 4 freebsd (416G)
sf-03 ls -ls /dev/ada*
0 crw-r- 1 root operator0, 78 Jan 18 14:35 /dev/ada0
0 crw-r- 1 root operator0, 80 Jan 18 14:35 /dev/ada0p1
0 crw-r- 1 root operator0, 81 Jan 18 14:35 /dev/ada0p2
0 crw-r- 1 root operator0, 82 Jan 18 14:35 /dev/ada0p3
0 crw-r- 1 root operator0, 83 Jan 18 14:35 /dev/ada0s4
0 crw-r- 1 root operator0, 79 Jan 18 14:35 /dev/ada1
0 crw-r- 1 root operator0, 84 Jan 18 14:35 /dev/ada1p1
0 crw-r- 1 root operator0, 85 Jan 18 14:35 /dev/ada1p2
0 crw-r- 1 root operator0, 86 Jan 18 14:35 /dev/ada1p3
0 crw-r- 1 root operator0, 87 Jan 18 14:35 /dev/ada1s4
next I did:
# gstripe label s0 /dev/ada{0,1}s4
and on the console the following appeared:
GEOM_STRIPE: Device s0 activated.
GEOM_STRIPE: Cannot add disk gptid/bd0f6e54-22ea-11e0-b27c-001b245d5a5b to s0
(error=17).
GEOM_STRIPE: Cannot add disk gptid/bdf7d563-22ea-11e0-b27c-001b245d5a5b to s0
(error=17).
is this realy an error?
It looks like a similar type of error as people commonly see with
gmirror - a race with glabel. If you don't use glabel, the easyest way
would be to disable some of kern.geom.label.*.
I think one way to solve it would be for glabel export an attribute for
devices (providers) on which this is possible (i.e. those whose size
doesn't change from the underlying devices) which could be checked by
such GEOM classes.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: NFS: file too large
:Well, since a server specifies the maximum file size it can :handle, it seems good form to check for that in the client. :(Although I'd agree that a server shouldn't crash if a read/write : that goes beyond that limit.) : :Also, as Matt notes, off_t is signed. As such, it looks to me like :the check could mess up if uio_offset it right near 0x7fff, :so that uio-ui_offset + uio-uio_resid ends up negative. I think the :check a little above that for uio_offset 0 should also check :uio_offset + uio_resid 0 to avoid this. : :rick Yes, though doing an overflow check in C, at least with newer versions of GCC, requires a separate comparison. The language has been mangled pretty badly over the years. if (a + b a) - can be optimized-out by the compiler if (a + b 0) - also can be optimized-out by the compiler x = a + b; if (x a) - this is ok (best method) x = a + b; if (x 0) - this is ok This sort of check may already be made in various places (e.g. by UFS and/or uio), since negative offsets are used to identify meta-data in UFS. -Matt Matthew Dillon dil...@backplane.com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: NFS: file too large
:Well, since a server specifies the maximum file size it can :handle, it seems good form to check for that in the client. :(Although I'd agree that a server shouldn't crash if a read/write : that goes beyond that limit.) : :Also, as Matt notes, off_t is signed. As such, it looks to me like :the check could mess up if uio_offset it right near 0x7fff, :so that uio-ui_offset + uio-uio_resid ends up negative. I think the :check a little above that for uio_offset 0 should also check :uio_offset + uio_resid 0 to avoid this. : :rick Yes, though doing an overflow check in C, at least with newer versions of GCC, requires a separate comparison. The language has been mangled pretty badly over the years. if (a + b a)- can be optimized-out by the compiler if (a + b 0)- also can be optimized-out by the compiler x = a + b; if (x a)- this is ok (best method) x = a + b; if (x 0)- this is ok This sort of check may already be made in various places (e.g. by UFS and/or uio), since negative offsets are used to identify meta-data in UFS. -Matt Matthew Dillon dil...@backplane.com my question, badly written, was why not let the underlaying fs (ufs, zfs, etc) have the last word, instead of the nfsclient having to guess? Is there a problem in sending back the error? danny ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: gpart/gstripe problems?
On 18.1.2011 16:48, Daniel Braniss wrote:
I have:
sf-03 gpart show
= 34 976773101 ada0 GPT (466G)
34128 1 freebsd-boot (64K)
1624194304 2 freebsd-ufs (2.0G)
4194466 100663296 3 freebsd-swap (48G)
104857762 871915373 4 freebsd (416G)
= 34 976773101 ada1 GPT (466G)
34128 1 freebsd-boot (64K)
1624194304 2 freebsd-ufs (2.0G)
4194466 100663296 3 freebsd-swap (48G)
104857762 871915373 4 freebsd (416G)
sf-03 ls -ls /dev/ada*
0 crw-r- 1 root operator0, 78 Jan 18 14:35 /dev/ada0
0 crw-r- 1 root operator0, 80 Jan 18 14:35 /dev/ada0p1
0 crw-r- 1 root operator0, 81 Jan 18 14:35 /dev/ada0p2
0 crw-r- 1 root operator0, 82 Jan 18 14:35 /dev/ada0p3
0 crw-r- 1 root operator0, 83 Jan 18 14:35 /dev/ada0s4
0 crw-r- 1 root operator0, 79 Jan 18 14:35 /dev/ada1
0 crw-r- 1 root operator0, 84 Jan 18 14:35 /dev/ada1p1
0 crw-r- 1 root operator0, 85 Jan 18 14:35 /dev/ada1p2
0 crw-r- 1 root operator0, 86 Jan 18 14:35 /dev/ada1p3
0 crw-r- 1 root operator0, 87 Jan 18 14:35 /dev/ada1s4
next I did:
# gstripe label s0 /dev/ada{0,1}s4
and on the console the following appeared:
GEOM_STRIPE: Device s0 activated.
GEOM_STRIPE: Cannot add disk gptid/bd0f6e54-22ea-11e0-b27c-001b245d5a5b to
s0
(error=17).
GEOM_STRIPE: Cannot add disk gptid/bdf7d563-22ea-11e0-b27c-001b245d5a5b to
s0
(error=17).
is this realy an error?
It looks like a similar type of error as people commonly see with
gmirror - a race with glabel. If you don't use glabel, the easyest way
would be to disable some of kern.geom.label.*.
I think one way to solve it would be for glabel export an attribute for
devices (providers) on which this is possible (i.e. those whose size
doesn't change from the underlying devices) which could be checked by
such GEOM classes.
thanks for the explanation, I did
kern.geom.label.gptid.enable=0
which 'solved' it, since I don't have use for it (mainly I don't know
what it's good for :-).
danny
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
