On Mon, 13 Jul 2015 17:38:35 -0400, Selva Nair wrote:
As with any dedup solution, performance does take a hit and its often
not worth it unless you have a lot of duplication in the data.
This is so only in some volumes in our case, but it appears that zfs
permits this to be enabled/disabled
yeah, i read somewhere that zfs DOES have separate tuning for metadata
and data cache, but i need to read up on that more.
as for heavy block duplication: daily backups of the whole system = alot of
dupe.
/kc
On Thu, Jul 16, 2015 at 05:42:32PM +, Andrew Gideon said:
On Mon, 13 Jul
On Tue, 14 Jul 2015 08:59:25 +0200, Paul Slootman wrote:
btrfs has support for this: you make a backup, then create a btrfs
snapshot of the filesystem (or directory), then the next time you make a
new backup with rsync, use --inplace so that just changed parts of the
file are written to the
Andrew Gideon c182driv...@gideon.org wrote:
btrfs has support for this: you make a backup, then create a btrfs
snapshot of the filesystem (or directory), then the next time you make a
new backup with rsync, use --inplace so that just changed parts of the
file are written to the same blocks
On Mon 13 Jul 2015, Andrew Gideon wrote:
On the other hand, I do confess that I am sometimes miffed at the waste
involved in a small change to a very large file. Rsync is smart about
moving minimal data, but it still stores an entire new copy of the file.
What's needed is a file system
And what's performance like? I've heard lots of COW systems performance
drops through the floor when there's many snapshots.
/kc
On Tue, Jul 14, 2015 at 08:59:25AM +0200, Paul Slootman said:
On Mon 13 Jul 2015, Andrew Gideon wrote:
On the other hand, I do confess that I am sometimes
Ken Chase rsync-list-m...@sizone.org wrote:
And what's performance like? I've heard lots of COW systems performance
drops through the floor when there's many snapshots.
For BTRFS I'd suspect the performance penalty to be fairly small. Snapshots can
be done in different ways, and the way BTRFS
On Mon, 13 Jul 2015 02:19:23 +, Andrew Gideon wrote:
Look at tools like inotifywait, auditd, or kfsmd to see what's easily
available to you and what best fits your needs.
[Though I'd also be surprised if nobody has fed audit information into
rsync before; your need doesn't seem all that
Andrew Gideon c182driv...@gideon.org wrote:
These both bring me to the idea of using some file system auditing
mechanism to drive - perhaps with an --include-from or --files-from -
what rsync moves.
Where I get stuck is that I cannot envision how I can provide rsync with
a limited list
inotifywatch or equiv, there's FSM stuff (filesystem monitor) as well.
constantData had a product we used years ago - a kernel module that dumped
out a list of any changed files out some /proc or /dev/* device and they
had a whole toolset that ate the list (into some db) and played it out
as it
Andrew Gideon c182driv...@gideon.org wrote:
However, you've made be a little
apprehensive about storebackup. I like the lack of a need for a restore
tool. This permits all the standard UNIX tools to be applied to
whatever I might want to do over the backup, which is often *very*
On Mon, Jul 13, 2015 at 5:19 PM, Simon Hobson li...@thehobsons.co.uk
wrote:
What's needed is a file system that can do what hard links do, but at the
file page level. I imagine that this would work using the same Copy On
Write logic used in managing memory pages after a fork().
Well some
12 matches
Mail list logo
