On Fri, Jan 7, 2011 at 11:15 AM, Carl Cook <cac...@quantum-sci.com> wrote: > > On Fri 07 January 2011 08:14:17 Hubert Kario wrote: >> I'd suggest at least >> mkfs.btrfs -m raid1 -d raid0 /dev/sdc /dev/sdd >> if you really want raid0 > > I don't fully understand -m or -d. Why would this make a truer raid0 that > with no options?
this will give you RAID0 for your data, but RAID1 for your metadata, making it less likely that the FS itself gets corrupted, even though you will lose some data in crash cases, if i understand correctly. > Is it necessary to use fdisk on new drives in creating a BTRFS multi-drive > array? Or is this all that's needed: > # mkfs.btrfs /dev/sdb /dev/sdc > # btrfs filesystem show depends on whether you need /boot partitions or other partitions. what you have works fine though. > Is this related to 'subvolumes'? The FAQ implies that a subvolume is like a > directory, but also like a partition. What's the rationale for being able to > create a subvolume under a subvolume, as Hubert says so he can "use the > shadow_copy module for samba to publish the snapshots to windows clients." > I don't have any windows clients, but what difference does his structure make? just his preference to put it there... the snapshot of a snapshot can go anywhere. it doesn't have to reside under it's "parent", the parent was just used as a base, it's not bound to it in any way AFAIK. > How do you know what options to rsync are on by default? I can't find this > anywhere. For example, it seems to me that --perms -ogE --hard-links and > --delete-excluded should be on by default, for a true sync? the links and command Freddie Cash posted are a really good base to work from. > So for my system where there is a backup server, I guess I run the rsync > daemon on the backup server which presents a port, then when the other > systems decide it's time for a backup (cron) they: > - stop mysql, dump the database somewhere, start mysql; > - connect to the backup server's rsync port and dump their data to > (hopefully) some specific place there. > Right? you don't have to stop mysql, you just need to "freeze" any new, incoming writes, and flush (ie. let finish) whatever is happening right now. this ensures mysql is _internally_ consistent on the disk. see comment by Lloyd Standish here: http://dev.mysql.com/doc/refman/5.1/en/backup-methods.html C Anthony -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
