Re: [zfs-discuss] "NearLine SAS"?

On Tue, Jan 19, 2010 at 1:06 AM, Erik Trimble wrote: > stupid question here: I understand the advantages of dual-porting a drive > with a FC interface, but for SAS, exactly what are the advantages other than > being able to read and write simultaneously (obviously, only from the > on-drive cach

Re: [zfs-discuss] "NearLine SAS"?

Tim Cook wrote: On Tue, Jan 19, 2010 at 12:16 AM, Erik Trimble > wrote: A poster in another forum mentioned that Seagate (and Hitachi, amongst others) is now selling something labeled as "NearLine SAS" storage (e.g. Seagate's NL35 series). Is it

Re: [zfs-discuss] "NearLine SAS"?

On Tue, Jan 19, 2010 at 12:16 AM, Erik Trimble wrote: > A poster in another forum mentioned that Seagate (and Hitachi, amongst > others) is now selling something labeled as "NearLine SAS" storage (e.g. > Seagate's NL35 series). > > Is it me, or does this look like nothing more than their standar

[zfs-discuss] "NearLine SAS"?

A poster in another forum mentioned that Seagate (and Hitachi, amongst others) is now selling something labeled as "NearLine SAS" storage (e.g. Seagate's NL35 series). Is it me, or does this look like nothing more than their standard 7200-rpm enterprise drives with a SAS or FC interface inste

Re: [zfs-discuss] Is ZFS internal reservation excessive?

Daniel Carosone wrote: On Mon, Jan 18, 2010 at 03:25:56PM -0800, Erik Trimble wrote: Hopefully, once BP rewrite materializes (I know, I'm treating this much to much as a Holy Grail, here to save us from all the ZFS limitations, but really...), we can implement defragmentation which will seri

Re: [zfs-discuss] Snapshot that won't go away.

Daniel Carosone wrote: On Mon, Jan 18, 2010 at 05:52:25PM +1300, Ian Collins wrote: Is it the parent snapshot for a clone? I'm almost certain it isn't. I haven't created any clones and none show in zpool history. What about snapshot holds? I don't know if (and doubt wheth

Re: [zfs-discuss] Is ZFS internal reservation excessive?

Richard Elling wrote: On Jan 18, 2010, at 3:25 PM, Erik Trimble wrote: Given my (imperfect) understanding of the internals of ZFS, the non-ZIL portions of the reserved space are there mostly to insure that there is sufficient (reasonably) contiguous space for doing COW. Hopefully, once BP

Re: [zfs-discuss] Snapshot that won't go away.

On Mon, Jan 18, 2010 at 05:52:25PM +1300, Ian Collins wrote: >> Is it the parent snapshot for a clone? >> > I'm almost certain it isn't. I haven't created any clones and none show > in zpool history. What about snapshot holds? I don't know if (and doubt whether) these are in S10, but since

Re: [zfs-discuss] New ZFS Intent Log (ZIL) device available - Beta program now open!

On Mon, Jan 18, 2010 at 8:48 PM, Charles Hedrick wrote: > From the web page it looks like this is a card that goes into the computer > system. That's not very useful for enterprise applications, as they are > going to want to use an external array that can be used by a redundant pair > of servers.

Re: [zfs-discuss] New ZFS Intent Log (ZIL) device available - Beta program now open!

>From the web page it looks like this is a card that goes into the computer >system. That's not very useful for enterprise applications, as they are going >to want to use an external array that can be used by a redundant pair of >servers. I'm very interested in a cost-effective device that will

[zfs-discuss] how are free blocks are used?

Hi all, I was wondering, when blocks are freed as part COW process are the old blocks put on the top or bottom of the freeblock list? The question came about looking a thin provisioning using zfs on top of dynamically expanding disk images (VDI). If the free blocks are put at the end free block

Re: [zfs-discuss] Best 1.5TB drives for consumer RAID?

Thanks. Newegg shows quite a good customer rating for that drive: 70% rated it with 5 stars, and 11% with four stars, with 240 ratings. Seems like some people have complained about them sleeping - presumable to save power, although others report they don't, so I'll need to look into that more.

Re: [zfs-discuss] Is ZFS internal reservation excessive?

On Jan 18, 2010, at 3:25 PM, Erik Trimble wrote: > Given my (imperfect) understanding of the internals of ZFS, the non-ZIL > portions of the reserved space are there mostly to insure that there is > sufficient (reasonably) contiguous space for doing COW. Hopefully, once BP > rewrite materialize

Re: [zfs-discuss] Is ZFS internal reservation excessive?

On Mon, Jan 18, 2010 at 03:25:56PM -0800, Erik Trimble wrote: > Hopefully, once BP rewrite materializes (I know, I'm treating this > much to much as a Holy Grail, here to save us from all the ZFS > limitations, but really...), we can implement defragmentation which > will seriously reduce the amou

Re: [zfs-discuss] zfs send/receive as backup - reliability?

On Mon, Jan 18, 2010 at 01:38:16PM -0800, Richard Elling wrote: > The Solaris 10 10/09 zfs(1m) man page says: > > The format of the stream is committed. You will be able > to receive your streams on future versions of ZFS. > > I'm not sure when that hit snv, but obviously it wa

Re: [zfs-discuss] Is ZFS internal reservation excessive?

Tim Cook wrote: On Mon, Jan 18, 2010 at 3:49 PM, Richard Elling mailto:richard.ell...@gmail.com>> wrote: On Jan 18, 2010, at 7:55 AM, Jesus Cea wrote: > zpool and zfs report different free space because zfs takes into account > an internal reservation of 32MB or 1/64 of the c

Re: [zfs-discuss] Is ZFS internal reservation excessive?

On 2010-Jan-19 00:26:27 +0800, Jesus Cea wrote: >On 01/18/2010 05:11 PM, David Magda wrote: >> Ext2/3 uses 5% by default for root's usage; 8% under FreeBSD for FFS. >> Solaris (10) uses a bit more nuance for its UFS: > >That reservation is to preclude users to exhaust diskspace in such a way >that

Re: [zfs-discuss] [nfs-discuss] Two pools, one flop-

On 01/18/2010 07:50 PM, Tom Haynes wrote: CD wrote: On 01/18/2010 06:36 PM, Tom Haynes wrote: CD wrote: Greetings. I've go two pools, but can only access one of them from my linux-machine. Both pools got the same settings and acl. Both pools has sharenfs=on. Also, every filesystem got acl

Re: [zfs-discuss] [nfs-discuss] Two pools, one flop-

CD wrote: On 01/18/2010 06:36 PM, Tom Haynes wrote: CD wrote: Greetings. I've go two pools, but can only access one of them from my linux-machine. Both pools got the same settings and acl. Both pools has sharenfs=on. Also, every filesystem got aclinherit=passthrough NAME PROPERTY VALUE

Re: [zfs-discuss] I can't seem to get the pool to export...

On Sun, Jan 17, 2010 at 8:14 PM, Richard Elling wrote: > On Jan 16, 2010, at 10:03 PM, Travis Tabbal wrote: > > > Hmm... got it working after a reboot. Odd that it had problems before > that. I was able to rename the pools and the system seems to be running well > now. Irritatingly, the settings f

Re: [zfs-discuss] zfs send/receive as backup - reliability?

On 18/01/2010 18:28, Lassi Tuura wrote: Hi, Here is the big difference. For a professional backup people still typically use tapes although tapes have become expensive. I still believe that a set of compressed incremental star archives give you more features. Thanks for your comment

Re: [zfs-discuss] Is ZFS internal reservation excessive?

On Mon, Jan 18, 2010 at 3:49 PM, Richard Elling wrote: > On Jan 18, 2010, at 7:55 AM, Jesus Cea wrote: > > zpool and zfs report different free space because zfs takes into account > > an internal reservation of 32MB or 1/64 of the capacity of the pool, > > what is bigger. > > This space is also us

Re: [zfs-discuss] zfs send/receive as backup - reliability?

On Mon, Jan 18, 2010 at 07:34:51PM +0100, Lassi Tuura wrote: > > Consider then, using a zpool-in-a-file as the file format, rather than > > zfs send streams. > > This is an interesting suggestion :-) > > Did I understand you correctly that once a slice is written, zfs > won't rewrite it? In other

Re: [zfs-discuss] Is ZFS internal reservation excessive?

On Jan 18, 2010, at 7:55 AM, Jesus Cea wrote: > zpool and zfs report different free space because zfs takes into account > an internal reservation of 32MB or 1/64 of the capacity of the pool, > what is bigger. This space is also used for the ZIL. > So in a 2TB Harddisk, the reservation would be 3

Re: [zfs-discuss] zfs send/receive as backup - reliability?

On Jan 18, 2010, at 11:04 AM, Miles Nordin wrote: ... > Another problem is that the snv_112 man page says this: > > -8<- > The format of the stream is evolving. No backwards com- > patibility is guaranteed. You may not be able to receive > your streams on future ve

Re: [zfs-discuss] Boot Disk Configuration

On Jan 18, 2010, at 10:22 AM, Mr. T Doodle wrote: > I would like some opinions on what people are doing in regards to configuring > ZFS for root/boot drives: > > 1) If you have onbaord RAID controllers are you using them then creating the > ZFS pool (mirrored from hardware)? I let ZFS do the m

Re: [zfs-discuss] Is ZFS internal reservation excessive?

>> Ext2/3 uses 5% by default for root's usage; 8% under FreeBSD for FFS. >> Solaris (10) uses a bit more nuance for its UFS: > > That reservation is to preclude users to exhaust diskspace in such a way > that ever "root" can not login and solve the problem. No, the reservation in UFS/FFS is to kee

Re: [zfs-discuss] zfs send/receive as backup - reliability?

> "mg" == Mike Gerdts writes: > "tt" == Toby Thain writes: > "tb" == Thomas Burgess writes: mg> Yet it is used in ZFS flash archives on Solaris 10 and are mg> slated for use in the successor to flash archives. in FLAR, ``if a single bit's flipped, the whole archive and any

Re: [zfs-discuss] zfs send/receive as backup - reliability?

Hi, > .. it's hard to beat the convenience of a "backup file" format, for > all sorts of reasons, including media handling, integration with other > services, and network convenience. Yes. > Consider then, using a zpool-in-a-file as the file format, rather than > zfs send streams. This is an i

Re: [zfs-discuss] zfs send/receive as backup - reliability?

Hi, > Here is the big difference. For a professional backup people still typically > use tapes although tapes have become expensive. > > I still believe that a set of compressed incremental star archives give you > more features. Thanks for your comments! I think I roughly understand the featu

[zfs-discuss] Boot Disk Configuration

I would like some opinions on what people are doing in regards to configuring ZFS for root/boot drives: 1) If you have onbaord RAID controllers are you using them then creating the ZFS pool (mirrored from hardware)? 2) How many slices? lol I can't seem to find any best practices such as the old

Re: [zfs-discuss] zfs send/receive as backup - reliability?

Hi, >> I am considering building a modest sized storage system with zfs. Some >> of the data on this is quite valuable, some small subset to be backed >> up "forever", and I am evaluating back-up options with that in mind. > > You don't need to store the "zfs send" data stream on your backup medi

Re: [zfs-discuss] Is ZFS internal reservation excessive?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/18/2010 05:11 PM, David Magda wrote: > On Jan 18, 2010, at 10:55, Jesus Cea wrote: > >> zpool and zfs report different free space because zfs takes into account >> an internal reservation of 32MB or 1/64 of the capacity of the pool, >> what is b

Re: [zfs-discuss] Is ZFS internal reservation excessive?

On Jan 18, 2010, at 10:55, Jesus Cea wrote: zpool and zfs report different free space because zfs takes into account an internal reservation of 32MB or 1/64 of the capacity of the pool, what is bigger. So in a 2TB Harddisk, the reservation would be 32 gigabytes. Seems a bit excessive to me

[zfs-discuss] Is ZFS internal reservation excessive?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 zpool and zfs report different free space because zfs takes into account an internal reservation of 32MB or 1/64 of the capacity of the pool, what is bigger. So in a 2TB Harddisk, the reservation would be 32 gigabytes. Seems a bit excessive to me...

Re: [zfs-discuss] zfs send/receive as backup - reliability?

or you might do something like: http://milek.blogspot.com/2009/12/my-presentation-at-losug.html however in your case if all your clients are running zfs only filesystems then relaying just on zfs send|recv might be a good idea. -- Robert Milkowski http://milek.blogspot.com _

Re: [zfs-discuss] zfs send/receive as backup - reliability?

On 18/01/2010 08:59, Phil Harman wrote: YMMV. At a recent LOSUG meeting we were told of a case where rsync was faster than an incremental zfs send/recv. But I think that was for a mail server with many tiny files (i.e. changed blocks are very easy to find in files with very few blocks). Af

Re: [zfs-discuss] Backing up a ZFS pool

On Mon, Jan 18, 2010 at 03:24:19AM -0500, Edward Ned Harvey wrote: > Unless I am mistaken, I believe, the following is not possible: > > On the source, create snapshot "1" > Send snapshot "1" to destination > On the source, create snapshot "2" > Send incremental, from "1" to "2" to the destination

Re: [zfs-discuss] Recordsize...

On 17/01/2010 20:34, Bob Friesenhahn wrote: On Mon, 18 Jan 2010, Tristan Ball wrote: Is there a way to check the recordsize of a given file, assuming that the filesystems recordsize was changed at some point? This would be problematic since a file may consist of different size records (at le

Re: [zfs-discuss] zfs send/receive as backup - reliability?

On Mon, Jan 18, 2010 at 3:59 AM, Phil Harman wrote: > YMMV. At a recent LOSUG meeting we were told of a case where rsync was > faster than an incremental zfs send/recv. But I think that was for a mail > server with many tiny files (i.e. changed blocks are very easy to find in > files with very fe

Re: [zfs-discuss] Backing up a ZFS pool

Edward Ned Harvey wrote: Personally, I like to start with a fresh "full" image once a month, and then do daily incrementals for the rest of the month. This doesn't buy you anything. ZFS isn't like traditional backups. If you never send another full, then eventually the delta from

Re: [zfs-discuss] Recordsize...

On Mon, Jan 18, 2010 at 10:22 AM, Richard Elling wrote: > On Jan 17, 2010, at 11:59 AM, Tristan Ball wrote: >> Is there a way to check the recordsize of a given file, assuming that the >> filesystems recordsize was changed at some point? > > I don't know of an easy way to do this. can't you use

Re: [zfs-discuss] zfs send/receive as backup - reliability?

YMMV. At a recent LOSUG meeting we were told of a case where rsync was faster than an incremental zfs send/recv. But I think that was for a mail server with many tiny files (i.e. changed blocks are very easy to find in files with very few blocks). However, I don't see why further ZFS perfom

Re: [zfs-discuss] Backing up a ZFS pool

Le 18 janv. 10 à 09:24, Edward Ned Harvey a écrit : Personally, I like to start with a fresh "full" image once a month, and then do daily incrementals for the rest of the month. This doesn't buy you anything. ZFS isn't like traditional backups. If you never send another full, then eventuall

Re: [zfs-discuss] Recordsize...

Richard Elling wrote: Tristan Ball wrote: Also - Am I right in thinking that if a 4K write is made to a filesystem block with a recordsize of 8K, then the original block is read (assuming it's not in the ARC), before the new block is written elsewhere (the "copy", from copy on write)? This

Re: [zfs-discuss] Backing up a ZFS pool

> > Personally, I like to start with a fresh "full" image once a month, > and then do daily incrementals for the rest of the month. > > This doesn't buy you anything. ZFS isn't like traditional backups. If you never send another full, then eventually the delta from the original to the present wil

Re: [zfs-discuss] zfs send/receive as backup - reliability?

> Consider then, using a zpool-in-a-file as the file format, rather than > zfs send streams. That's a pretty cool idea. Then you've still got the entire zfs volume inside of a file, but you're able to mount and extract individual files if you want, and you're able to pipe your zfs send directly t

Re: [zfs-discuss] zfs send/receive as backup - reliability?

> I still believe that a set of compressed incremental star archives give > you > more features. Big difference there is that in order to create an incremental star archive, star has to walk the whole filesystem or folder that's getting backed up, and do a "stat" on every file to see which files h