On 12 maj 2010, at 22.39, Miles Nordin wrote:
>> "bh" == Brandon High writes:
>
>bh> If you boot from usb and move your rpool from one port to
>bh> another, you can't boot. If you plug your boot sata drive into
>bh> a different port on the motherboard, you can't
>bh> boot. A
> "bh" == Brandon High writes:
bh> The devid for a USB device must change as it moves from port
bh> to port.
I guess it was tl;dr the first time I said this, but:
the old theory was that a USB device does not get a devid because it
is marked ``removeable'' in some arcane SCSI pa
On Wed, May 12, 2010 at 1:39 PM, Miles Nordin wrote:
> root pool. It's only used for finding other pools. ISTR the root
> pool is found through devid's that grub reads from the label on the
> BIOS device it picks, and then passes to the kernel. note that
Ok, that makes more sense with what I'v
> "bh" == Brandon High writes:
bh> If you boot from usb and move your rpool from one port to
bh> another, you can't boot. If you plug your boot sata drive into
bh> a different port on the motherboard, you can't
bh> boot. Apparently if you are missing a device from your rpool
On May 12, 2010, at 3:23 AM, Brandon High wrote:
On Tue, May 11, 2010 at 10:13 PM, Richard Elling > wrote:
But who needs usability? This is unix, man.
I must have missed something. For the past few years I have
routinely
booted with unimportable pools because I often use ramdisks. Sure,
On Tue, May 11, 2010 at 10:13 PM, Richard Elling
wrote:
>> But who needs usability? This is unix, man.
>
> I must have missed something. For the past few years I have routinely
> booted with unimportable pools because I often use ramdisks. Sure,
> I get FMA messages, but that doesn't affect the
On 12 maj 2010, at 05.31, Brandon High wrote:
> On Tue, May 11, 2010 at 8:17 PM, Richard Elling
> wrote:
>> boot single user and mv it (just like we've done for fstab/vfstab for
>> the past 30+ years :-)
>
> It would be nice to have a grub menu item that ignores the cache, so
> if you know you'
On 10 maj 2010, at 20.04, Miles Nordin wrote:
>> "bh" == Brandon High writes:
>
>bh> The drive should be on the same USB port because the device
>bh> path is saved in the zpool.cache. If you removed the
>bh> zpool.cache, it wouldn't matter where the drive was plugged
>bh> in
On May 11, 2010, at 8:31 PM, Brandon High wrote:
> On Tue, May 11, 2010 at 8:17 PM, Richard Elling
> wrote:
>> boot single user and mv it (just like we've done for fstab/vfstab for
>> the past 30+ years :-)
>
> It would be nice to have a grub menu item that ignores the cache, so
> if you know yo
On Tue, May 11, 2010 at 8:17 PM, Richard Elling
wrote:
> boot single user and mv it (just like we've done for fstab/vfstab for
> the past 30+ years :-)
It would be nice to have a grub menu item that ignores the cache, so
if you know you've removed a USB drive, you don't need to muck about
in sing
On May 11, 2010, at 3:26 PM, Brandon High wrote:
> On Mon, May 10, 2010 at 11:04 AM, Miles Nordin wrote:
>>> "bh" == Brandon High writes:
>>bh> The drive should be on the same USB port because the device
>>bh> path is saved in the zpool.cache. If you removed the
>>
>> I thought it
On Mon, May 10, 2010 at 11:04 AM, Miles Nordin wrote:
>> "bh" == Brandon High writes:
> bh> The drive should be on the same USB port because the device
> bh> path is saved in the zpool.cache. If you removed the
>
> I thought it was supposed to go by devid.
zpool.cache saves the device
> "bh" == Brandon High writes:
bh> The drive should be on the same USB port because the device
bh> path is saved in the zpool.cache. If you removed the
bh> zpool.cache, it wouldn't matter where the drive was plugged
bh> in.
I thought it was supposed to go by devid.
There was
On 05/ 7/10 10:07 PM, Bill McGonigle wrote:
On 05/07/2010 11:08 AM, Edward Ned Harvey wrote:
I'm going to continue encouraging you to staying "mainstream,"
because what
people do the most is usually what's supported the best.
If I may be the contrarian, I hope Matt keeps experimenting with th
> - Poweroff with USB drive connected or removed, Solaris will not boot
> unless USB drive is
> connected, and in some cases need to be attached to the exact same
> USB port when last
> attached. Is this a bug ?
Possibly hitting this?
http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug
On 05/07/2010 11:08 AM, Edward Ned Harvey wrote:
I'm going to continue encouraging you to staying "mainstream," because what
people do the most is usually what's supported the best.
If I may be the contrarian, I hope Matt keeps experimenting with this,
files bugs, and they get fixed. His use
On Fri, May 7, 2010 at 2:51 AM, Matt Keenan wrote:
> - Poweroff with USB drive connected or removed, Solaris will not boot unless
> USB drive is
> connected, and in some cases need to be attached to the exact same USB port
> when last
> attached. Is this a bug ?
There's a known issue in recent
> From: Matt Keenan [mailto:matt...@opensolaris.org]
>
> After some playing around I've noticed some kinks particularly around
> booting.
I'm going to continue encouraging you to staying "mainstream," because what
people do the most is usually what's supported the best. I think you'll
have a mor
After some playing around I've noticed some kinks particularly around
booting.
Some scenarios :
- Poweroff with USB drive connected or removed, Solaris will not boot
unless USB drive is
connected, and in some cases need to be attached to the exact same
USB port when last
attached. Is thi
Based on comments, some people say nay, some say yah. so I decided
to give it a spin, and see
how I get on.
To make my mirror bootable I followed instructions posted here :
http://www.taiter.com/blog/2009/04/opensolaris-200811-adding-disk.html
I plan to do a quick write up myself of my
On Thu, 6 May 2010, Daniel Carosone wrote:
That said, I'd also recommend a scrub on a regular basis, once the
resilver has completed, and that will trawl through all the data and
take all that time you were worried about anyway. For a 200G disk,
full, over usb, I'd expect around 4-5 hours. Tha
On Wed, 5 May 2010, Edward Ned Harvey wrote:
Here are the obstacles I think you'll have with your proposed solution:
#1 I think all the entire used portion of the filesystem needs to resilver
every time. I don't think there's any such thing as an incremental
resilver.
It sounds like you are
On Wed, May 05, 2010 at 04:34:13PM -0400, Edward Ned Harvey wrote:
> The suggestion I would have instead, would be to make the external drive its
> own separate zpool, and then you can incrementally "zfs send | zfs receive"
> onto the external.
I'd suggest doing both, to different destinations :)
Glenn Lagasse wrote:
How about ease-of-use, all you have to do is plug in the usb disk and
zfs will 'do the right thing'. You don't have to remember to run zfs
send | zfs receive, or bother with figuring out what to send/recv etc
etc etc.
It should be possible to automate that via syseventd/s
* Edward Ned Harvey (solar...@nedharvey.com) wrote:
> > From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
> > boun...@opensolaris.org] On Behalf Of Matt Keenan
> >
> > Just wondering whether mirroring a USB drive with main laptop disk for
> > backup purposes is recommended or not.
> >
> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
> boun...@opensolaris.org] On Behalf Of Matt Keenan
>
> Just wondering whether mirroring a USB drive with main laptop disk for
> backup purposes is recommended or not.
>
> Plan would be to connect the USB drive, once or twice a week
Hi Matt,
Don't know if it's recommended or not, but I've been doing it for close
to 3 years on my OpenSolaris laptop, it saved me a few times like last
week when my internal drive died :)
/peter
On 2010-05-04 20.33, Matt Keenan wrote:
Hi,
Just wondering whether mirroring a USB drive with m
Hi,
Just wondering whether mirroring a USB drive with main laptop disk for
backup purposes is recommended or not.
Current setup, single root pool set up on 200GB internal laptop drive :
$ zpool status
pool: rpool
state: ONLINE
scrub: non requested
config :
NAMESTATE RE
28 matches
Mail list logo
