* device delete progress
@ 2014-09-21 2:09 Russell Coker
2014-09-21 8:34 ` Duncan
2014-09-21 17:12 ` Chris Murphy
0 siblings, 2 replies; 6+ messages in thread
From: Russell Coker @ 2014-09-21 2:09 UTC (permalink / raw)
To: linux-btrfs
We need to have a way to determine the progress of a device delete operation.
Also for a balance of a RAID-1 that has more than 2 devices it would be good
to know how much space is used on each device.
Could btrfs fi df be extended to show information separately for each device?
--
My Main Blog http://etbe.coker.com.au/
My Documents Blog http://doc.coker.com.au/
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: device delete progress
2014-09-21 2:09 device delete progress Russell Coker
@ 2014-09-21 8:34 ` Duncan
2014-09-22 9:49 ` David Sterba
2014-09-21 17:12 ` Chris Murphy
1 sibling, 1 reply; 6+ messages in thread
From: Duncan @ 2014-09-21 8:34 UTC (permalink / raw)
To: linux-btrfs
Russell Coker posted on Sun, 21 Sep 2014 12:09:11 +1000 as excerpted:
> We need to have a way to determine the progress of a device delete
> operation.
> Also for a balance of a RAID-1 that has more than 2 devices it would be
> good to know how much space is used on each device.
>
> Could btrfs fi df be extended to show information separately for each
> device?
btrfs fi show should give you at least some minimal per-device stats,
today. Enough to at least have some idea of the progress of a balance
when adding/removing devices.
Longer term, there has been discussion of extending/changing the fi df
format and making it far more verbose, including the information found in
btrfs fi show as well, and making everything potentially per-device. I
hadn't paid a whole lot of attention to the details, however.
Alternatively, leave df more or less as it is (perhaps extending it a bit
but attempting not to kill existing scripts using it) and put the detail
in a new btrfs filesystem usage. This sounds rather more reasonable to
me.
Either way the idea is to give people a single command that combines the
current output of fi show and fi df, ideally displaying per-device and
filesystem totals both, in enough verbosity to avoid the unintuitive and
arcane btrfs specific knowledge required today to interpret it.
I had originally presumed that such a change would happen before the
experimental labels came off, but it didn't. I don't know the timetable
for it now, or even if it's still planned, as IIRC the discussion died
away back in the btrfs-progs 3.12 era and I expected to see it in 3.14
and it wasn't there, so I don't know...
--
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] 6+ messages in thread
* Re: device delete progress
2014-09-21 2:09 device delete progress Russell Coker
2014-09-21 8:34 ` Duncan
@ 2014-09-21 17:12 ` Chris Murphy
1 sibling, 0 replies; 6+ messages in thread
From: Chris Murphy @ 2014-09-21 17:12 UTC (permalink / raw)
To: Btrfs BTRFS
On Sep 20, 2014, at 8:09 PM, Russell Coker <russell@coker.com.au> wrote:
> We need to have a way to determine the progress of a device delete operation.
> Also for a balance of a RAID-1 that has more than 2 devices it would be good
> to know how much space is used on each device.
btrfs replace does do this; but in the use case where the user wants to permanently shrink a filesystem by only removing a device, then it might be nice to have a status for that too considering it might be an 8TB helium drive and take a while.
Chris Murphy
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: device delete progress
2014-09-21 8:34 ` Duncan
@ 2014-09-22 9:49 ` David Sterba
2014-09-22 16:29 ` Duncan
0 siblings, 1 reply; 6+ messages in thread
From: David Sterba @ 2014-09-22 9:49 UTC (permalink / raw)
To: Duncan; +Cc: linux-btrfs
On Sun, Sep 21, 2014 at 08:34:33AM +0000, Duncan wrote:
> Russell Coker posted on Sun, 21 Sep 2014 12:09:11 +1000 as excerpted:
>
> > We need to have a way to determine the progress of a device delete
> > operation.
> > Also for a balance of a RAID-1 that has more than 2 devices it would be
> > good to know how much space is used on each device.
> >
> > Could btrfs fi df be extended to show information separately for each
> > device?
>
> btrfs fi show should give you at least some minimal per-device stats,
> today. Enough to at least have some idea of the progress of a balance
> when adding/removing devices.
Up to now this is the only way to see the progress.
> Longer term, there has been discussion of extending/changing the fi df
> format and making it far more verbose, including the information found in
> btrfs fi show as well, and making everything potentially per-device. I
> hadn't paid a whole lot of attention to the details, however.
>
> Alternatively, leave df more or less as it is (perhaps extending it a bit
> but attempting not to kill existing scripts using it) and put the detail
> in a new btrfs filesystem usage. This sounds rather more reasonable to
> me.
>
> Either way the idea is to give people a single command that combines the
> current output of fi show and fi df, ideally displaying per-device and
> filesystem totals both, in enough verbosity to avoid the unintuitive and
> arcane btrfs specific knowledge required today to interpret it.
>
> I had originally presumed that such a change would happen before the
> experimental labels came off, but it didn't. I don't know the timetable
> for it now, or even if it's still planned, as IIRC the discussion died
> away back in the btrfs-progs 3.12 era and I expected to see it in 3.14
> and it wasn't there, so I don't know...
The upcomming 3.17 release should contain all the 'new df' patches that
were unfortunatelly delayed. There are some minor issues to be fixed but
I hope it'll be ready close to the kernel 3.17 release.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: device delete progress
2014-09-22 9:49 ` David Sterba
@ 2014-09-22 16:29 ` Duncan
2014-09-22 19:23 ` Duncan
0 siblings, 1 reply; 6+ messages in thread
From: Duncan @ 2014-09-22 16:29 UTC (permalink / raw)
To: linux-btrfs
David Sterba posted on Mon, 22 Sep 2014 11:49:55 +0200 as excerpted:
> The upcomming 3.17 release should contain all the 'new df' patches that
> were unfortunatelly delayed. There are some minor issues to be fixed but
> I hope it'll be ready close to the kernel 3.17 release.
Will that fix my "unknown" chunk profiles too?
I expected either userspace 3.16 or kernel 3.17 to fix that, but I'm
running both (well, kernel 3.17 git, since the release hasn't happened
yet) and still seeing the unknown chunk profiles.
Either that, or if userspace 3.16 and kernel 3.17 should have fixed it,
I'm triggering a bug somewhere.
--
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] 6+ messages in thread
* Re: device delete progress
2014-09-22 16:29 ` Duncan
@ 2014-09-22 19:23 ` Duncan
0 siblings, 0 replies; 6+ messages in thread
From: Duncan @ 2014-09-22 19:23 UTC (permalink / raw)
To: linux-btrfs
Duncan posted on Mon, 22 Sep 2014 16:29:26 +0000 as excerpted:
> David Sterba posted on Mon, 22 Sep 2014 11:49:55 +0200 as excerpted:
>
>> The upcomming 3.17 release should contain all the 'new df' patches that
>> were unfortunatelly delayed. There are some minor issues to be fixed
>> but I hope it'll be ready close to the kernel 3.17 release.
>
> Will that fix my "unknown" chunk profiles too?
Never mind. I see that in the 3.16.1 announcement, which I imagine I'll
get next update.
--
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] 6+ messages in thread
end of thread, other threads:[~2014-09-22 19:23 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-09-21 2:09 device delete progress Russell Coker
2014-09-21 8:34 ` Duncan
2014-09-22 9:49 ` David Sterba
2014-09-22 16:29 ` Duncan
2014-09-22 19:23 ` Duncan
2014-09-21 17:12 ` Chris Murphy
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).