I had promised to weigh in on my experiences using ZFS in a production
environment. We've been testing it for a few months now, and confidence
is building. We've started using it in production about a month ago
after months of non production testing.
I'll append my thoughts in a cross-post from
On 1/6/2014 3:26 PM, Cliff Pratt wrote:
> Grub only needs to know about the filesystems that it uses to boot the
> system. Mounting of the other file systems including /var is the
> responsibility of the system that has been booted. I suspect that you have
> something else wrong if you can't boot w
Grub only needs to know about the filesystems that it uses to boot the
system. Mounting of the other file systems including /var is the
responsibility of the system that has been booted. I suspect that you have
something else wrong if you can't boot with /var/ on ZFS.
I may be wrong, but I don't t
On 11/30/2013 06:20 AM, Andrew Holway wrote:
> Hey,
>
> http://zfsonlinux.org/epel.html
>
> If you have a little time and resource please install and report back
> any problems you see.
>
Andrew,
I want to run /var on zfs, but when I try to move /var over it won't
boot thereafter, with errors ab
On 12/19/2013, 04:00 , li...@benjamindsmith.com wrote:
> BackupPC is a great product, and if I knew of it and/or it was available
> when I started, I would likely have used it instead of cutting code. Now
> that we've got BackupBuddy working and integrated, we aren't going to be
> switching as it
On Wed, Dec 18, 2013 at 5:41 PM, Lists wrote:
> On 12/18/2013 03:04 PM, Les Mikesell wrote:
>> For the people who don't know, backuppc builds a directory tree for
>> each backup run where the full runs are complete and the incrementals
>> normally only contain the changed files. However, when you
On 12/18/2013 3:41 PM, Lists wrote:
> Should I read this as "BackupPC now has its own filesystem driver"? If
> so, wow. Or do you mean that there are command line tools to read/copy
> BackupPC save points?
web interface, primarily. you can restore any portion of any version of
any backup to the
On 12/18/2013 03:04 PM, Les Mikesell wrote:
> For the people who don't know, backuppc builds a directory tree for
> each backup run where the full runs are complete and the incrementals
> normally only contain the changed files. However, when you access the
> incremental backups through the web int
On Wed, Dec 18, 2013 at 3:13 PM, Lists wrote:
> >
> I would differentiate BackupBuddy in that there is no "incremental" and
> "full" distinction. All backups are "full" in the truest sense of the
> word,
For the people who don't know, backuppc builds a directory tree for
each backup run where the
On 12/18/2013 07:50 AM, Les Mikesell wrote:
> I've always considered backuppc to be one of those rare things that
> you set up once and it takes care of itself for years. If you have
> problems with it, someone on the backuppc mail list might be able to
> help. It does tend to be slower than nat
On Wed, Dec 18, 2013 at 9:13 AM, Chuck Munro wrote:
>
> Not presumptuous at all! I have not heard of backupbuddy (or dirvish),
> so I should investigate. Your description makes it sound somewhat like
> OS-X Time Machine, which I like a lot. I did try backuppc but it got a
> bit complex to manag
On 12/18/2013, 04:00 , li...@benjamindsmith.com wrote:
> I may be being presumptuous, and if so, I apologize in advance...
>
> It sounds to me like you might consider a disk-to-disk backup solution.
> I could suggest dirvish, BackupPC, or our own home-rolled rsync-based
> solution that works rath
On 12/14/2013 08:50 AM, Chuck Munro wrote:
> Hi Ben,
>
> Yes, the initial replication of a large filesystem is *very* time
> consuming! But it makes sleeping at night much easier. I did have to
> crank up the inotify kernel parameters by a significant amount.
>
> I did the initial replication usi
On 12/14/2013, 04:00 , li...@benjamindsmith.com wrote:
> We checked lsyncd out and it's most certainly an very interesting tool.
> I*will* be using it in the future!
>
> However, we found that it has some issues scaling up to really big file
> stores that we haven't seen (yet) with ZFS.
>
> For
On 12/04/2013 06:05 AM, John Doe wrote:
> Not sure if I already mentioned it but maybe have a look at:
> http://code.google.com/p/lsyncd/
We checked lsyncd out and it's most certainly an very interesting tool.
I *will* be using it in the future!
However, we found that it has some issues scalin
On 04.12.2013 14:05, n...@li.nux.ro wrote:
>>> >>On 04.12.2013 14:05, John Doe wrote:
> From: Lists
>
>>> >>Our next big test is to try out ZFS filesystem send/receive in
>>> >>lieu
>>> >>of
>>> >>our current backup processes based on rsync. Rsync i
On 05.12.2013 22:46, Chuck Munro wrote:
>> On 04.12.2013 14:05, John Doe wrote:
From: Lists
>> Our next big test is to try out ZFS filesystem send/receive in
>> lieu
>> of
>> our current backup processes based on rsync. Rsync is a fabulous
>> tool,
>> but is begi
> On 04.12.2013 14:05, John Doe wrote:
>> >From: Lists
>> >
>>> >>Our next big test is to try out ZFS filesystem send/receive in lieu
>>> >>of
>>> >>our current backup processes based on rsync. Rsync is a fabulous
>>> >>tool,
>>> >>but is beginning to show performance/scalability issues dealing wi
On 04.12.2013 14:05, John Doe wrote:
> From: Lists
>
>> Our next big test is to try out ZFS filesystem send/receive in lieu
>> of
>> our current backup processes based on rsync. Rsync is a fabulous
>> tool,
>> but is beginning to show performance/scalability issues dealing with
>> the
>> many
From: Lists
> Our next big test is to try out ZFS filesystem send/receive in lieu of
> our current backup processes based on rsync. Rsync is a fabulous tool,
> but is beginning to show performance/scalability issues dealing with the
> many millions of files being backed up, and we're hoping th
On Sat, Nov 30, 2013 at 9:20 AM, Andrew Holway wrote:
> Hey,
>
> http://zfsonlinux.org/epel.html
>
> If you have a little time and resource please install and report back
> any problems you see.
>
> A filesystem or Volume sits within a zpool
> a zpool is made up of vdevs
> vdevs are made up of blo
Andrew,
We've been testing ZFS since about 10/24, see my original post (and
replies) asking about its suitability "ZFS on Linux in production" on
this list. So far, it's been rather impressive. Enabling compression
better than halved the disk space utilization in a low/medium bandwidth
(mainly
Hey,
http://zfsonlinux.org/epel.html
If you have a little time and resource please install and report back
any problems you see.
A filesystem or Volume sits within a zpool
a zpool is made up of vdevs
vdevs are made up of block devices.
zpool is similar to LVM volume
vdev is similar to raid set
23 matches
Mail list logo