Re: Decrease/increase XFS partitions
On Wed, Aug 17, 2016 at 09:38:50AM -0400, Gene Heskett wrote:
> This last link is from 2008. It does seem to be difficult, and only
> accomplishable by a full dump, repartition and recovery. The latter
> would not be a problem if a regular backup is being done. But I've no
> knowldge about how tar handles an xfs filesystem. Ack the man page, its
> agnostic as there is zero mention of the filesytem in use.
>
> I use amanda as the tar manager here but my nightly backups are rather
> tiny compared to 13Tb, rarely exceeding 20 gigabytes for 4 machines.
>
> With my wrapper script, I can lose the main drive, and put in a new one,
> and have it recovered to its state as of about 3am this morning in 4 or
> 5 hours. Any transactions after that time would be lost but 98% of that
> is email traffic. Non-commercial IOW. Using commodity 1T drives, I have
> the last 30 days worth of amanda backups on one of them using virtual
> tapes. Unlike a tape drive that always has to spend the winter holidays
> in Oklahoma City getting rebuilt, I have random (fast) access to my
> data. That drive is now about 4 years old, has had 25 re-allocated
> sectors for much of that time, less than 50 power ups, and shows 45%
> usage in a df -h report right now. Whats not to like? :)
>
> What does zfs do for one that ext4 can't that makes it attractive to use?
ZFS has:
- checksum of all data, so you can detect when you are reading
data that wasn't what you wrote
- if RAID is set up, correction of that data, including knowing
which cop(ies) pass the checksum
- built in snapshotting, faster and more efficient than LVM's
version
- built in send/receive - like dump, but with better than rsync
efficiency
- read and write caching for spinning disks can be done with
SSDs, to provide a significant price/performance advantage
for large storage.
Of these, I guess the last one wouldn't be too interesting to
you.
-dsr-
Reply to: