Have gone with the move stuff off then finish convert plan. Convert has now finished and I'm 60% of the way through moving all the big files back on.
Thanks for the help guys. On Mon, Jan 26, 2015 at 2:23 AM, Marc Joliet <mar...@gmx.de> wrote: > Am Fri, 23 Jan 2015 08:46:23 +0000 (UTC) > schrieb Duncan <1i5t5.dun...@cox.net>: > >> Marc Joliet posted on Fri, 23 Jan 2015 08:54:41 +0100 as excerpted: >> >> > Am Fri, 23 Jan 2015 04:34:19 +0000 (UTC) >> > schrieb Duncan <1i5t5.dun...@cox.net>: >> > >> >> Gareth Pye posted on Fri, 23 Jan 2015 08:58:08 +1100 as excerpted: >> >> >> >> > What are the chances that splitting all the large files up into sub >> >> > gig pieces, finish convert, then recombine them all will work? >> >> >> > [...] >> >> Option 2: Since new files should be created using the desired target >> >> mode (raid1 IIRC), you may actually be able to move them off and >> >> immediately back on, so they appear as new files and thus get created >> >> in the desired mode. >> > >> > With current coreutils, wouldn't that also work if he moves the files to >> > another (temporary) subvolume? (And with future coreutils, by copying >> > the files without using reflinks and then removing the originals.) >> >> If done correctly, yes. >> >> However, "off the filesystem" is far simpler to explain over email or the >> like, and is much less ambiguous in terms of "OK, but did you do it >> 'correctly'" if it doesn't end up helping. If it doesn't work, it >> doesn't work. If "move to a different subvolume under specific >> conditions in terms of reflinking and the like" doesn't work, there's >> always the question of whether it /really/ didn't work, or if somehow the >> instructions weren't clear enough and thus failure was simply the result >> of a failure to fully meet the technical requirements. >> >> Of course if I was doing it myself, and if I was absolutely sure of the >> technical details in terms of what command I had to use to be /sure/ it >> didn't simply reflink and thus defeat the whole exercise, I'd likely use >> the shortcut. But in reality, if it didn't work I'd be second-guessing >> myself and would probably move everything entirely off and back on to be >> sure, and knowing that, I'd probably do it the /sure/ way in the first >> place, avoiding the chance of having to redo it to prove to myself that >> I'd done it correctly. >> >> Of course, having demonstrated to myself that it worked, if I ever had >> the problem again, I might try the shortcut, just to demonstrate to my >> own satisfaction the full theory that the effect of the shortcut was the >> same as the effect of doing it the longer and more fool-proof way. But >> of course I'd rather not have the opportunity to try that second-half >> proof. =:^) >> >> Make sense? =:^) > > I was going to argue that my suggestion was hardly difficult to get right, but > then I read that cp defaults to --reflink=always and that it is not possible > to > turn off reflinks (i.e., there is no --reflink=never). > > So then would have to consider alternatives like dd, and, well, you are right, > I suppose :) . > > (Of course, with the *current* version of coreutils, the simple "mv somefile > tmp_subvol/; mv tmp_subvol/somefile ." will still work.) > > -- > Marc Joliet > -- > "People who think they know everything really annoy those of us who know we > don't" - Bjarne Stroustrup -- Gareth Pye Level 2 MTG Judge, Melbourne, Australia "Dear God, I would like to file a bug report" -- 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
