Re: rsync backup to ext3-formatted usb flash drive?



Thanks to Shachar Or and Ted Hilts for the suggestions, I might try them
sometime (particularly the nested filesystem idea, that's very clever :)

My main reply, below, is to Rick.

On Mon, 2008-08-11 at 18:33 -0400, Rick Thomas wrote:
On Aug 11, 2008, at 4:25 PM, Brian Wells wrote:

I'm looking at an alternative utility, svn-backup-dumps, in the same
package. I could do ~800 full backups, or many more incremental
backups
with a full backup here and there, before running out of space. That
would only write most blocks once or twice, and once it filled up I
could erase old backups with only one write and reuse it, right?
(If I
do this, should I reformat to FAT so the controllers won't be
confused?)

The inodes are going to be your problem in an ext3 filesystem, not
the data blocks. Keep that in mind. So you should be trying to
control the number of writes per inode. One way to get a better
handle on that is by using the "noatime" mount option. Or switching
to FAT, if your backup system supports FAT as a destination filesystem.

USB flash drives are not expensive -- cdw.com advertises a variety of
4GB drives for US$15-$20, and they aren't the cheapest by a good
shot. No matter what you finally wind up doing, I'd still plan to
replace the flash drive at least once a year. That works out to
about 5 US cents/day.

Rick

Looks like you caught some wishful thinking on my part. I guessed that
the inode blocks would still take a lot of writes, hence "most blocks"
instead of "all blocks"; but I don't know enough details about whether
inodes in ext3 are kept close together (i.e. in the same block) or not.

If they are not, then adding new files should create inodes in another
block, which shouldn't cause excessive writes to any single block. (The
access time change might, though.) Again, I don't know enough to be
sure, but I was hoping it might be so.

Interestingly, while I was researching on the web I found another issue:
the journal that ext3 keeps. Quoting http://en.wikipedia.org/wiki/Ext2

---Begin Quote---
ext2 is still recommended over journaling file systems on bootable USB
flash drives and other solid-state drives. ext2 performs fewer writes
than ext3 since it does not need to write to the journal. As the major
aging factor of a flash chip is the number of erase cycles, and as those
happen frequently on writes, this increases the life span of the
solid-state device. Another good practice for filesystems on flash
devices is the use of the noatime mount option, for the same reason.
---End Quote---

So it looks like there's another factor that might run the drive into
the ground. Wonderful, I think I see why most people keep FAT on them.

On the noatime issue, GNOME in etch mounts the drive automatically for
me when I plug it in; I'm not sure how to configure GNOME to use custom
mount options, short of unmounting and remounting manually every time I
stick the drive in. I think I'm also seeing one kind of reason that
many people hate automagical GUIs. Can someone point me to the docs?

Thanks,
Brian



--
To UNSUBSCRIBE, email to debian-user-REQUEST@xxxxxxxxxxxxxxxx
with a subject of "unsubscribe". Trouble? Contact listmaster@xxxxxxxxxxxxxxxx



Relevant Pages

  • Re: can you make a hard disk read-only?
    ... installation, and the fixed drive will have the read-write partitions ... rebuild the ISO9660 filesystem for the fixed drive. ... By the way for flash drives that others have mentioned, ...
    (comp.os.linux.security)
  • Re: [patch] ext2/3: document conditions when reliable operation is possible
    ... the data on the filesystem has not been horribly mangled. ... further writes to the disk can trash unrelated existing data because it's ... disk can trash unrelated existing data _anyway_, because the flash block ... Today we have cheap plentiful USB keys that act like hard drives, ...
    (Linux-Kernel)
  • Re: linux hard drive failed, clicking on bootup
    ... E) hard drives do and will fail; this can mostly only be predicted ... one's hardware, if the hardware is broken/defective (though it can ... * try a full read test of the filesystem, partition, volume, or full ... fsck/e2fsck - but with the -n option, so no writing is done to the ...
    (comp.os.linux.setup)
  • Re: Looking for a Text on ZFS
    ... Even a 64bit filesystem still has gigantic reserves of space and ... well the drives can still live on their own if they are ever seperated. ... Since I use HDs on my computers, I have had about 20 to 25 ...
    (freebsd-questions)
  • Recommendations for servers running SATA drives
    ... I'm forking the thread on fsck/soft-updates in hopes of getting some practical advice based on the discussion here of background fsck, softupdates and write-caching on SATA drives. ... that fact ignored, then the filesystem is either 1) worthless, or 2) ...
    (freebsd-stable)