On Tue, May 02, 2017 at 05:01:02AM +0000, Duncan wrote:
> Marc MERLIN posted on Mon, 01 May 2017 20:23:46 -0700 as excerpted:
>
> > Also, how is --mode=lowmem being useful?
>
> FWIW, I just watched your talk that's linked from the wiki, and wondered
> what you were doing these days as I hadn't seen any posts from you here
> for awhile.
First, sorry for the late reply. Because you didn't Cc me in the answer,
it went to a different folder where I only saw your replies now.
Off topic, but basically I'm not dead or anything, I have btrfs working
well enough to not mess with it further because I have many other
hobbies :) that is unless I put a new SAS card in my server, hit some
corruption bugs, and now I'm back spending days fixing the system.
> Well, that you're asking that question confirms you've not been following
> the list too closely... Of course that's understandable as people have
> other stuff to do, but just sayin'.
That's exactly right. I'm subscribed to way too many lists on way too
many topics to be up to date with all, sadly :(
> Of course on-list I'm somewhat known for my arguments propounding the
> notion that any filesystem that's too big to be practically maintained
> (including time necessary to restore from backups, should that be
> necessary for whatever reason) is... too big... and should ideally be
> broken along logical and functional boundaries into a number of
> individual smaller filesystems until such point as each one is found to
> be practically maintainable within a reasonably practical time frame.
> Don't put all the eggs in one basket, and when the bottom of one of those
> baskets inevitably falls out, most of your eggs will be safe in other
> baskets. =:^)
That's a valid point, and in my case, I can back it up/restore, it just
takes a bit of time, but most of the time is manually babysitting all
those subvolumes that I need to recreate by hand with btrfs send/restore
relationships, which all get lost during backup/restore.
This is the most painful part.
What's too big? I've only ever used a filesystem that fits on on a raid
of 4 data drives. That value has increased over time, but I don't have a
a crazy array of 20+ drives as a single filesystem, or anything.
Since drives have gotten bigger, but not that much faster, I use bcache
to make things more acceptable in speed.
> *BUT*, and here's the "go further" part, keep in mind that subvolume-read-
> only is a property, gettable and settable by btrfs property.
>
> So you should be able to unset the read-only property of a subvolume or
> snapshot, move it, then if desired, set it again.
>
> Of course I wouldn't expect send -p to work with such a snapshot, but
> send -c /might/ still work, I'm not actually sure but I'd consider it
> worth trying. (I'd try -p as well, but expect it to fail...)
That's an interesting point, thanks for making it.
In that case, I did have to destroy and recreate the filesystem since
btrfs check --repair was unable to fix it, but knowing how to reparent
read only subvolumes may be handy in the future, thanks.
Marc
--
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems ....
.... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/ | PGP 1024R/763BE901
--
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
