* Confining scrub to a subvolume
@ 2015-12-30 0:00 Sree Harsha Totakura
2015-12-30 17:39 ` David Sterba
0 siblings, 1 reply; 10+ messages in thread
From: Sree Harsha Totakura @ 2015-12-30 0:00 UTC (permalink / raw)
To: linux-btrfs
Hi,
Is it possible to confine scrubbing to a subvolume instead of the whole
file system?
The problem I am facing is that I have a 5 TB btrfs FS. On it I have
created subvolumes for weekly backups, personal photos, music, and
documents. Obviously, I am more concerned about my photos and documents
than my backups and music. Therefore, I would like to scrub the photos
and documents subvolumes more often than the backups subvolume. Would
this be possible with the current tools?
Regards,
Sree
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Confining scrub to a subvolume
2015-12-30 0:00 Confining scrub to a subvolume Sree Harsha Totakura
@ 2015-12-30 17:39 ` David Sterba
2015-12-30 18:26 ` Duncan
2015-12-30 19:26 ` Christoph Anton Mitterer
0 siblings, 2 replies; 10+ messages in thread
From: David Sterba @ 2015-12-30 17:39 UTC (permalink / raw)
To: Sree Harsha Totakura; +Cc: linux-btrfs
On Wed, Dec 30, 2015 at 01:00:34AM +0100, Sree Harsha Totakura wrote:
> Is it possible to confine scrubbing to a subvolume instead of the whole
> file system?
No. Srub reads the blocks from devices (without knowing which files own
them) and compares them to the stored checksums.
> [...] Therefore, I would like to scrub the photos
> and documents subvolumes more often than the backups subvolume. Would
> this be possible with the current tools?
The closest would be to read the files and look for any reported errors.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Confining scrub to a subvolume
2015-12-30 17:39 ` David Sterba
@ 2015-12-30 18:26 ` Duncan
2015-12-30 19:28 ` Christoph Anton Mitterer
2016-01-04 11:01 ` Sree Harsha Totakura
2015-12-30 19:26 ` Christoph Anton Mitterer
1 sibling, 2 replies; 10+ messages in thread
From: Duncan @ 2015-12-30 18:26 UTC (permalink / raw)
To: linux-btrfs
David Sterba posted on Wed, 30 Dec 2015 18:39:49 +0100 as excerpted:
> On Wed, Dec 30, 2015 at 01:00:34AM +0100, Sree Harsha Totakura wrote:
>> Is it possible to confine scrubbing to a subvolume instead of the whole
>> file system?
>
> No. Srub reads the blocks from devices (without knowing which files own
> them) and compares them to the stored checksums.
Of course if like me you prefer not to have all your data eggs in one
filesystem basket and have used partitions (or LVM) and multiple
independent btrfs, in which case you scrub the filesystem you want, and
don't worry about the others. =:^)
It definitely helps with maintenance time -- on SSDs with all under 50
GiB partitions, scrub times per btrfs are typically under a minute, and
btrfs check and balance times are similarly short. Plus, arranging to
have additional partitions exactly the same size to use as backups works
pretty nicely as well. =:^) OTOH, people routinely report days for
multi-terabyte btrfs maintenance commands on spinning rust. =:^(
Tho I do still have my media partition, along with backups, on reiserfs
on spinning rust. I should think about switching that over one of these
days...
>> [...] Therefore, I would like to scrub the photos and documents
>> subvolumes more often than the backups subvolume. Would this be
>> possible with the current tools?
>
> The closest would be to read the files and look for any reported errors.
That should work. Cat the files to /dev/null and check dmesg. For
single mode it should check the only copy. For raid1/10 or dup, running
two checks, ensuring one is even-PID while the other is odd-PID, should
work to check both copies, since the read-scheduler assigns copy based on
even/odd PID. Errors will show up in dmesg, as well as cat's STDERR.
Pretty clever thinking there. =:^)
--
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Confining scrub to a subvolume
2015-12-30 17:39 ` David Sterba
2015-12-30 18:26 ` Duncan
@ 2015-12-30 19:26 ` Christoph Anton Mitterer
2016-01-05 9:40 ` David Sterba
1 sibling, 1 reply; 10+ messages in thread
From: Christoph Anton Mitterer @ 2015-12-30 19:26 UTC (permalink / raw)
To: dsterba, Sree Harsha Totakura; +Cc: linux-btrfs
[-- Attachment #1: Type: text/plain, Size: 309 bytes --]
On Wed, 2015-12-30 at 18:39 +0100, David Sterba wrote:
> The closest would be to read the files and look for any reported
> errors.
Doesn't that fail for any multi-device setup, in which case btrfs reads
the blocks only from one device, and if that verifies, doesn't check
the other?
Cheers,
Chris.
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5313 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Confining scrub to a subvolume
2015-12-30 18:26 ` Duncan
@ 2015-12-30 19:28 ` Christoph Anton Mitterer
2015-12-30 20:57 ` Duncan
2016-01-04 11:01 ` Sree Harsha Totakura
1 sibling, 1 reply; 10+ messages in thread
From: Christoph Anton Mitterer @ 2015-12-30 19:28 UTC (permalink / raw)
To: Duncan, linux-btrfs
[-- Attachment #1: Type: text/plain, Size: 788 bytes --]
On Wed, 2015-12-30 at 18:26 +0000, Duncan wrote:
> That should work. Cat the files to /dev/null and check dmesg. For
> single mode it should check the only copy. For raid1/10 or dup,
> running
> two checks, ensuring one is even-PID while the other is odd-PID,
> should
> work to check both copies, since the read-scheduler assigns copy
> based on
> even/odd PID. Errors will show up in dmesg, as well as cat's STDERR.
That doesn't seem very reliable to me, to be honest... plus it wouldn't
work in any RAID56 or dupN (with n!=2) case, when that gets sooner or
later implemented.
Also, I'd kinda guess (or better said: hope) that the kernel's cache
would destroy these efforts, at least when the two reads happen mostly
in parallel.
Cheers,
Chris.
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5313 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Confining scrub to a subvolume
2015-12-30 19:28 ` Christoph Anton Mitterer
@ 2015-12-30 20:57 ` Duncan
2015-12-30 21:12 ` Christoph Anton Mitterer
0 siblings, 1 reply; 10+ messages in thread
From: Duncan @ 2015-12-30 20:57 UTC (permalink / raw)
To: linux-btrfs
Christoph Anton Mitterer posted on Wed, 30 Dec 2015 20:28:00 +0100 as
excerpted:
> On Wed, 2015-12-30 at 18:26 +0000, Duncan wrote:
>> That should work. Cat the files to /dev/null and check dmesg. For
>> single mode it should check the only copy. For raid1/10 or dup,
>> running two checks, ensuring one is even-PID while the other is
>> odd-PID, should work to check both copies, since the read-scheduler
>> assigns copy based on even/odd PID. Errors will show up in dmesg, as
>> well as cat's STDERR.
> That doesn't seem very reliable to me, to be honest... plus it wouldn't
> work in any RAID56 or dupN (with n!=2) case, when that gets sooner or
> later implemented.
Well, yes, but right now except on raid56... and there's a good chance
it'll work for a year at least, as I've seen no first-patches yet to
implement n-way (which I'm sure looking forward to), after which perhaps
he'll have implemented the multi-btrfs on partitions or lvm thing that I
actually prefer, myself.
Meanwhile, it's a pretty clever solution, I think. =:^)
> Also, I'd kinda guess (or better said: hope) that the kernel's cache
> would destroy these efforts, at least when the two reads happen mostly
> in parallel.
I was thinking run them in parallel, but you're right, you'd have to run
them serially and dumpcache between runs.
--
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Confining scrub to a subvolume
2015-12-30 20:57 ` Duncan
@ 2015-12-30 21:12 ` Christoph Anton Mitterer
0 siblings, 0 replies; 10+ messages in thread
From: Christoph Anton Mitterer @ 2015-12-30 21:12 UTC (permalink / raw)
To: linux-btrfs
[-- Attachment #1: Type: text/plain, Size: 597 bytes --]
On Wed, 2015-12-30 at 20:57 +0000, Duncan wrote:
> Meanwhile, it's a pretty clever solution, I think. =:^)
Well the problem with such workaround-solutions is... end-users get
used to it, rely on it, and suddenly they don't work anymore (which the
user wouldn't probably notice, though).
> I was thinking run them in parallel, but you're right, you'd have to
> run
> them serially and dumpcache between runs.
And, you'd need to clear the cache, at least for filesystems < memory
but even if not, I wouldn't be 100% that one can safely do without
clearing the cache.
Cheers,
Chris.
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5313 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Confining scrub to a subvolume
2015-12-30 18:26 ` Duncan
2015-12-30 19:28 ` Christoph Anton Mitterer
@ 2016-01-04 11:01 ` Sree Harsha Totakura
2016-01-06 8:06 ` Duncan
1 sibling, 1 reply; 10+ messages in thread
From: Sree Harsha Totakura @ 2016-01-04 11:01 UTC (permalink / raw)
To: Duncan, linux-btrfs
On 12/30/2015 07:26 PM, Duncan wrote:
> David Sterba posted on Wed, 30 Dec 2015 18:39:49 +0100 as excerpted:
>
>> On Wed, Dec 30, 2015 at 01:00:34AM +0100, Sree Harsha Totakura wrote:
>>> Is it possible to confine scrubbing to a subvolume instead of the whole
>>> file system?
>>
>> No. Srub reads the blocks from devices (without knowing which files own
>> them) and compares them to the stored checksums.
>
> Of course if like me you prefer not to have all your data eggs in one
> filesystem basket and have used partitions (or LVM) and multiple
> independent btrfs, in which case you scrub the filesystem you want, and
> don't worry about the others. =:^)
I considered it, but after reading somewhere (couldn't find the source)
that having a single btrfs could be beneficial, I decided not to.
Clearly, it doesn't seem to be true in this case.
Thank you all for your comments and suggestions. I will be using
different btrfs file systems based.
Regards,
Sree Harsha Totakura
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Confining scrub to a subvolume
2015-12-30 19:26 ` Christoph Anton Mitterer
@ 2016-01-05 9:40 ` David Sterba
0 siblings, 0 replies; 10+ messages in thread
From: David Sterba @ 2016-01-05 9:40 UTC (permalink / raw)
To: Christoph Anton Mitterer; +Cc: dsterba, Sree Harsha Totakura, linux-btrfs
On Wed, Dec 30, 2015 at 08:26:00PM +0100, Christoph Anton Mitterer wrote:
> On Wed, 2015-12-30 at 18:39 +0100, David Sterba wrote:
> > The closest would be to read the files and look for any reported
> > errors.
> Doesn't that fail for any multi-device setup, in which case btrfs reads
> the blocks only from one device, and if that verifies, doesn't check
> the other?
That's right, it's not equivalent to the scrub.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Confining scrub to a subvolume
2016-01-04 11:01 ` Sree Harsha Totakura
@ 2016-01-06 8:06 ` Duncan
0 siblings, 0 replies; 10+ messages in thread
From: Duncan @ 2016-01-06 8:06 UTC (permalink / raw)
To: linux-btrfs
Sree Harsha Totakura posted on Mon, 04 Jan 2016 12:01:58 +0100 as
excerpted:
> On 12/30/2015 07:26 PM, Duncan wrote:
>> David Sterba posted on Wed, 30 Dec 2015 18:39:49 +0100 as excerpted:
>>
>>> On Wed, Dec 30, 2015 at 01:00:34AM +0100, Sree Harsha Totakura wrote:
>>>> Is it possible to confine scrubbing to a subvolume instead of the
>>>> whole file system?
>>>
>>> No. Srub reads the blocks from devices (without knowing which files
>>> own them) and compares them to the stored checksums.
>>
>> Of course if like me you prefer not to have all your data eggs in one
>> filesystem basket and have used partitions (or LVM) and multiple
>> independent btrfs, in which case you scrub the filesystem you want, and
>> don't worry about the others. =:^)
>
> I considered it, but after reading somewhere (couldn't find the source)
> that having a single btrfs could be beneficial, I decided not to.
> Clearly, it doesn't seem to be true in this case.
It depends very much on your viewpoint and use-case.
Arguably, btrfs should /eventually/ provide a more flexible alternative
to lvm as a volume manager, letting you do subvolumes, restrict them if
desired to some maximum size via quotas (which remain buggy and
unreliable on btrfs ATM so don't try to use them for that yet), and let
you "magically" add and remove devices from a single btrfs storage pool,
changing quota settings as desired, without the hassle of managing
individual partitions and multiple filesystems.
But IMO at least, and I'd guess in the opinion of most on the list, btrfs
at its present "still stabilizing, not yet fully stable and mature"
status, remains at least partially unsuited to that. Besides general
stability, some options, including quotas, simply don't work reliably
yet, and other tools and features have yet to be developed.
But even in the future, when btrfs is stable and many are using these
sorts of logical volume management and integrated filesystem features to
do everything on a single filesystem, I'm still very likely to consider
that a higher risk than I'm willing to take, because it'll still be
ultimately putting all those data eggs in the filesystem basket, which if
the bottom falls out...
In addition, I actually tried, for instance, big partitioned mdraids,
with several filesystems each on their own partition of that mdraid, and
I eventually came to the conclusion that at some point, they simply get
too big, and maintenance simply takes too long, to be practical for me.
When adding a multi-TB device to a big mdraid takes days... I'd much
rather have multiple much smaller mdraids, or now, btrfs raids, and
perhaps still take days overall to do the same thing if I'm doing it to
all of them, but in increments of a few hours each on multiple much
smaller capacity ones, rather than a single-shot instance that takes days.
Meanwhile, my current btrfs layout is multiple mostly raid1 btrfs, on a
pair of partitioned SSDs, which each partition under 50 GiB, under 100
GiB for the raid1 filesystem, 50 on each device. On that, scrubs
normally take, literally, under a minute, full balances well under ten,
per filesystem. Sure, to do every single filesystem might still take say
a half hour, but most of the time, not all filesystems are even mounted,
and most of the time, I only need to scrub or balance perhaps three of
them, so while if they were all in one I might do it in say 20 minutes,
and if I had to do all of them it might take me 30 because I have to
repeatedly type in the command for each one, because I have to do only
three of them, it's done in five minutes or less.
That's in addition to the fact that if a filesystem dies, I've only a
fraction of the data to btrfs restore or to copy over from backup,
because most of it was on other filesystems, many of which weren't even
mounted or in some cases (my /) were mounted read-only, so they're just
fine and I don't have to btrfs restore or copy back over from backup, for
them.
These are lessons I've learned in a quarter century of working with
computers, about a decade on MS, a decade and a half later this year, on
Linux. They may not always apply to everyone, but I've definitely
learned how to spare myself unnecessary pain, as I've learned how they
apply to me. =:^)
--
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
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2016-01-06 8:06 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-12-30 0:00 Confining scrub to a subvolume Sree Harsha Totakura
2015-12-30 17:39 ` David Sterba
2015-12-30 18:26 ` Duncan
2015-12-30 19:28 ` Christoph Anton Mitterer
2015-12-30 20:57 ` Duncan
2015-12-30 21:12 ` Christoph Anton Mitterer
2016-01-04 11:01 ` Sree Harsha Totakura
2016-01-06 8:06 ` Duncan
2015-12-30 19:26 ` Christoph Anton Mitterer
2016-01-05 9:40 ` David Sterba
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.