Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756924Ab1FIINh (ORCPT ); Thu, 9 Jun 2011 04:13:37 -0400 Received: from mail.lang.hm ([64.81.33.126]:52027 "EHLO bifrost.lang.hm" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754765Ab1FIINe (ORCPT ); Thu, 9 Jun 2011 04:13:34 -0400 Date: Thu, 9 Jun 2011 01:13:20 -0700 (PDT) From: david@lang.hm X-X-Sender: dlang@asgard.lang.hm To: "Amir G." cc: Lukas Czerner , Yongqiang Yang , linux-ext4@vger.kernel.org, tytso@mit.edu, linux-kernel@vger.kernel.org, sandeen@redhat.com Subject: Re: [PATCH v1 00/30] Ext4 snapshots In-Reply-To: Message-ID: References: <1307459283-22130-1-git-send-email-amir73il@users.sourceforge.net> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4005 Lines: 90 On Thu, 9 Jun 2011, Amir G. wrote: > On Thu, Jun 9, 2011 at 9:50 AM, Lukas Czerner wrote: >> On Thu, 9 Jun 2011, Yongqiang Yang wrote: >> >>> On Thu, Jun 9, 2011 at 11:18 AM, Amir G. wrote: >>>> On Thu, Jun 9, 2011 at 4:59 AM, Yongqiang Yang wrote: >> >> You see, when it comes to the full fs snapshots I am not convinced that >> it is *very* useful, yes it might have some users, but you can alway >> take the safe way and do lvm snapshots (or better use the new multisnap) >> for backup, without need to modify stable filesystem code. >> > > You think like a developer. Try talking to some sys admins. > Especially ones that worked with Solaris/ZFS or NetApp. > See what they think about snapshots and about the LVM alternative... > Snapshots have addictive qualities. Ones you've used them, you can't > go back to not having them. > Imagine how people used to live before the 'Undo' button and imagine > that your employer forced you to use an editor without an Undo button. > This is the kind of feedback I got from sys admins that moved from Solaris > to Linux. as a sysadmin, it's a _wonderful_ tool to have for any system that has people editing/saving files on directly. > >> Also, I do not buy the whole argument of "not have to create separate disk >> space for snapshot". It is actually better for sysadmins, because you >> have perfect control on what is going on, how much space is used for >> your snapshots and how much is used by your data. You can always easily >> extend the snapshot volume, or let it die silently when it is too old >> and too big. >> > > Seriously, Lukas, talk to sys admins. > Letting the snapshot die silently is the worst possible thing that a snapshots > implementation can do (for long lived snapshots). that depends on the site policy. sometimes it is better to loose snapshots than to run out of disk space and halt the system, sometimes you would rather halt the system. the policy of what happens when you run out of space should not be a kernel decision, the desired behavior varies far too much. this includes being able to say things like "I want to always have 10% of my disk allocated to snapshots, but if there's more free space, go ahead and use it, but always keep at least 10% of the disk free so that you don't have to halt new writes while you clear space" or "if you run out of space, try and keep the oldest snapshot and the newest snapshot, delete other snapshots in between before touching either of these" >> How does it actually work on ext4 snapshots ? When you're going to >> rewrite a file, you will never know how much disk space it'll take in >> advance, am I right ? Is the filesystem accounting for the snapshot size >> as well ? or is it hidden ? > > It's not hidden, it's accounted for as a regular file (usually owned by root). > You need a bit of scripting to gather the disk space used by snapshots (du). the worst case when you re-write a file is that it will take the full amount of space that the file currently takes (as if you wrote a new copy of the file and some process had a filehandle open on the old copy, preventing the space from being reclaimed, so it's far from being a new problem) see the note above about the need to be able to remove snapshots when you are out of space. since snapshots tend to be small compared to the filesystems they protect (not in all cases, but if you are covering the entire system with one snapshot that would be the way to bet), having the ability to put the snapshot metadata off on a smaller/faster disk would be helpful. having the ability to snapshot just specific files/directories would be a killer feature IMHO David Lang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/