On Tue, Jan 25, 2011 at 2:01 AM, Steven Whitehouse <swhiteho@xxxxxxxxxx> wrote: >> On Mon, Jan 24, 2011 at 6:55 PM, Jankowski, Chris >> <Chris.Jankowski@xxxxxx> wrote: >> > A few comments, which might contrast uses of GFS2 and XFS in enterprise class production environments: >> > >> > 3. >> > GFS2 provides only tar(1) as a backup mechanism. >> > Unfortunately, tar(1) does not cope efficiently with sparse files, >> > which many applications create. >> > As an exercise create a 10 TB sparse file with just one byte of non-null data at the end. >> > Then try to back it up to disk using tar(1). >> > The tar image will be correctly created, but it will take many, many hours. >> > Dump(8) would do the job in a blink, but is not available for GFS2 filesystem. >> > However, XFS does have XFS specific dump(8) command and will backup sparse files >> > efficiently. >> > > You don't need dump in order to do this (since dump reads directly from > the block device itself, that would be problematic on GFS/GFS2 anyway). > All that is required is a backup too which support the FIEMAP ioctl. I > don't know if that has made it into tar yet, I suspect probably not. > If cluster snapshot is in the hand of another develop team (that may not see it as a high priority), a GFS2 specific dump command could be a good alternative. The bottom line here is GFS2 is lacking a sensible (read as "easy to use") backup strategy that can significantly jeopardize its deployment. Of couse, this depends on .... someone has to be less stubborn and willing to move GFS2's inode number away from its physical disk block number. Cough ! -- Wendy -- Linux-cluster mailing list Linux-cluster@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/linux-cluster
