From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from plane.gmane.org ([80.91.229.3]:38521 "EHLO plane.gmane.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754124Ab3LPPA2 (ORCPT ); Mon, 16 Dec 2013 10:00:28 -0500 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1VsZei-0002ih-KO for linux-btrfs@vger.kernel.org; Mon, 16 Dec 2013 16:00:24 +0100 Received: from ip68-231-22-224.ph.ph.cox.net ([68.231.22.224]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 16 Dec 2013 16:00:24 +0100 Received: from 1i5t5.duncan by ip68-231-22-224.ph.ph.cox.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 16 Dec 2013 16:00:24 +0100 To: linux-btrfs@vger.kernel.org From: Duncan <1i5t5.duncan@cox.net> Subject: Re: Blocket for more than 120 seconds Date: Mon, 16 Dec 2013 15:00:01 +0000 (UTC) Message-ID: References: <46A0D70E-99DF-46FE-A4E8-71E9AC45129F@colorremedies.com> <337E6C9D-298E-4F77-91D7-648A7C65D360@colorremedies.com> <840381F8-BDCA-43BF-A170-6E10C2908B8A@colorremedies.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Sender: linux-btrfs-owner@vger.kernel.org List-ID: Hans-Kristian Bakke posted on Mon, 16 Dec 2013 11:55:40 +0100 as excerpted: > Stupid me, I completely forgot that you can run multidisk arrays with > just block level partitions, just like with md raid! It will introduce a > rather significant management overhead in my case though, as managing > several individual partitions per drive is quite annoying with so many > drives. What I did here, both with mdraid and now with btrfs raid1, is use a parallel partition setup on all target drives. In a couple special cases it results in some wasted space[1], but for most cases it's possible to simply plan partition sizes so the end result after raid combination is the desired size. And some years ago I switched to GPT partitions, for checksummed/ redundant partition table reliability, partition naming (similar to filesystem labels but in the GPT partition table itself), and to not have to mess with primary/secondary/logical partitions. That lets me set partition names, which given the scheme I use for both partition names and filesystem labeling, means I have unique name/label IDs for everything, across multiple machines and with thumb-drives too! The scheme is 15 chars long, reiserfs' max label length since I was using it at the time I designed the scheme. Here's the content of text file I keep, documenting it: >>>>> * 15 characters long 123456789012345 ff bbB ymd ssssS t n Example: rt0005gmd3+9bc0 Function: ff: 2-char function abbreviation (bt/rt/lg, etc) Device ID (size, brand, 0-based number/letter) ssssS: 4-digit size, 1-char multiplier (m=meg, g=gig, etc) This is the size of the underlying media, NOT the partition! bbB 2-char media brand ID, 1-digit sequence number. pa=patriot, io=iomega, md=md/raid, etc. Note that /dev/md10=mda... Target/separator t: 1-char target ID and separator. .=aa1, +=workstation, %=both (bt/swap on portable disk) Date code ymd: 1-char-each year/month/day prepared y=last digit of year m=month (1-9abc) d=day (1-9a-v) Number (working, backup-n) n=copy number (zero-based) So together, we have 2 chars of function, 8 of size/mfr/n as device-id, 1 of target/separator, 3 of date prepared, 1 of copy number. So our example: rt0005gmd3+9bc0 rt=root 0005gmd3=5-gig /dev/md3 +=targeted at the workstation 9bc0=2009.1112 (Nov. 12), first/main version. <<<<< For a multi-device btrfs, I set the "hardware" sequence number appropriately for the partitions, with the filesystem label identical, except its "hardware" sequence number is "x", indicating it's across multiple hardware devices. The "filesystem" sequence number, meanwhile, is 0 for the working copy, 1 for the primary backup, etc. With that scheme, I have both the partitions and the filesystems on top of them uniquely labeled with function, hardware/media ID (brand, size, sequence number), target machine, and partition/filesystem ID (date of layout, working/backup sequence number). If it ever got /too/ complex I could keep a list of them somewhere, but so far, it hasn't gotten beyond the context-manageable scope level, so between seeing the name/label and knowing the context of what I'm accessing, I've been able to track it without resorting to a written tracking list. But that's not to say you gotta do what I do. If you still find the administrative overhead of all those partitions too high, well so be it. This is just the solution that I've come up with after a couple decades of incremental modification, to where it works pretty well for me now. If some of the stuff I've come up with the hard way makes useful hints for someone else, great. Otherwise, just ignore it and do what works for you. It's your system and you're the one dealing with it, after all, not mine/me. =:^) > What happens If I do cp --reflink=auto from a NOCOW file in a NOCOW > folder to a folder with COW set on the same btrfs volume? Do I still get > "free" copying, and is the resulting file COW or NOCOW? I don't actually know as that doesn't fit my USE case so well, tho a comment I read awhile back hinted it may spit out an error. FWIW, I tend to either use symlinks one direction or the other or I'm trying to keep deliberately redundant backups where I don't want potential damage to kill the common-due-to-COW parts of both files, so I don't actually tend to find reflinks particularly useful here, even if I appreciate the flexibility that option allows. --- [1] For instance, swap with a hibernate image back before I switched to SSD (hibernate was broken on my new machine, last I checked about a year ago, and I've enough memory on this machine I usually don't fill it even with cache, so I wasn't hibernate or swap anyway, when I switched to SSD). The hibernate image must ordinarily be on a single device and should be half the size of RAM or so to avoid dumping cache to fit, but making all the parallel swap partitions that size made for a prohibitively large swap, that even if I WERE to need it, would take well longer to transfer all those gigs to/from spinning rust than I'd want to take, so one way or another, I'd never actually use it all. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman