Bob Friesenhahn writes:
> You might want to think a bit more before you get started. While
> there is an implicit usable filesystem at the pool root ('/rbk'),
> there is considerable value with creating subordinate filesystems
> using 'zfs create' because then you will be able to manage them muc
First, it fails because the destination directory doesn't exist. Then it
fails because it DOES exist. I really expected one of those to work. So,
what am I confused about now? (Running 2008.11)
# zpool import -R /backups/bup-ruin bup-ruin
# zfs send -R "z...@bup-20090222-054457utc" | zfs recei
on Sat Feb 21 2009, Miles Nordin wrote:
>> "da" == David Abrahams writes:
>> "ic" == Ian Collins writes:
>
> da> disadvantage of the recommended approaches shows up when you
> da> start taking advantage of ZFS to clone filesystems without
> da> replicating storage. Using "
On Sat, 21 Feb 2009, Harry Putnam wrote:
Probably the wrong move now that its clear how I screwed this up.
I'm thinking something like this might clean things up?
cd /rbk
Starting with:
ls -F .
chub/ harvey/ mob1/ mob1MyBackup.tib
zfs destroy -r mob1
mkdir -p mob1/acronis/022009/ mob1
Miles Nordin wrote:
ic> I wouldn't have any serious concerns about backing up
ic> snapshots provided the stream version was on the tape label
ic> and I had a backup of the Solaris release (or a virtual
ic> machine) that produced them.
I would have serious concerns doing that beca
Bob Friesenhahn writes:
I created a receptacle with zpool
zpool create zbk raidz1 c5t0d0 c5t1d0 c5t2d0
(With compression turned on)
As seen my zfs
zfs list zbk
NAME USED AVAIL REFER MOUNTPOINT
zbk106G 50.5G 106G /zbk
As seen by zpool
zpool list zbk
NAME SIZE USED AVAI
> "da" == David Abrahams writes:
> "ic" == Ian Collins writes:
da> disadvantage of the recommended approaches shows up when you
da> start taking advantage of ZFS to clone filesystems without
da> replicating storage. Using "zfs send" will avoid representing
da> the data t
On Sat, 21 Feb 2009, Tim wrote:
Well given that I *KNOW* Sun isn't making shit up as they go along, and I
have *SEEN* some of their plans under NDA, I'll just outright call bullshit.
I was trying to be nice about it. If you're making stuff up as you go
along that's likely why you're struggling.
On Thu, Feb 19, 2009 at 12:36:22PM -0800, Brandon High wrote:
> On Thu, Feb 19, 2009 at 6:18 AM, Gary Mills wrote:
> > Should I file an RFE for this addition to ZFS? The concept would be
> > to run ZFS on a file server, exporting storage to an application
> > server where ZFS also runs on top of
David Abrahams wrote:
David Magda ee.ryerson.ca> writes:
The format of the [zfs send] stream is evolving. No backwards
compatibility is guaranteed. You may not be able to receive your
streams on future versions of ZFS.
http://docs.sun.com/app/docs/doc/819-2240/zfs-1m
If you wa
On Feb 21, 2009, at 13:27, Tim wrote:
Well given that I *KNOW* Sun isn't making shit up as they go along,
and I
have *SEEN* some of their plans under NDA, I'll just outright call
bullshit.
I was trying to be nice about it. If you're making stuff up as you go
along that's likely why you're s
On Sat, Feb 21, 2009 at 12:18 PM, Bob Friesenhahn <
bfrie...@simple.dallas.tx.us> wrote:
>
> ZFS is principally already developed. It is now undergoing feature
> improvement, performance, and stability updates. Perhaps entries in the
> OpenSolaris bug tracking system may reveal what is requested
On Sat, 21 Feb 2009, Tim wrote:
No, he's not asking them to predict the future. Don't be a dick. He's
asking if they can share some of their intentions based on their current
internal roadmap. If you're telling me Sun doesn't have a 1yr/2yr/3yr
roadmap for ZFS I'd say we're all in some seriou
On Sat, Feb 21, 2009 at 11:26 AM, Bob Friesenhahn <
bfrie...@simple.dallas.tx.us> wrote:
> On Sat, 21 Feb 2009, David Abrahams wrote:
>
>>
>>> If you want to do back ups of your file system use a documented
>>> utility (tar, cpio, pax, zip, etc.).
>>>
>>
>> Well understood. But does anyone know t
On Sat, 21 Feb 2009, David Abrahams wrote:
If you want to do back ups of your file system use a documented
utility (tar, cpio, pax, zip, etc.).
Well understood. But does anyone know the long-term intentions of
the ZFS developers in this area? The one big disadvantage of the
It would be nice
David Magda ee.ryerson.ca> writes:
> > The format of the [zfs send] stream is evolving. No backwards
> > compatibility is guaranteed. You may not be able to receive your
> > streams on future versions of ZFS.
>
> http://docs.sun.com/app/docs/doc/819-2240/zfs-1m
>
> If you want to do back
2009/2/18 Ragnar Sundblad :
> For our file- and mail servers we have been using mirrored raid-5
> chassises, with disksuite and ufs. This has served us well, and the
> By some reason that I haven't gotten
> yet, zfs doesn't allow you to put "raids" upon each other, like
> mirrors/stripes/parity ra
17 matches
Mail list logo
