* 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 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
* 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
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).