Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

-p doesn't follow expecations... #29

Open
fiveangle opened this issue Apr 19, 2021 · 4 comments
Open

-p doesn't follow expecations... #29

fiveangle opened this issue Apr 19, 2021 · 4 comments

Comments

@fiveangle
Copy link

fiveangle commented Apr 19, 2021

One would expect dfc -p <filesystem> to result in either exact string matching, or substring matching, but it seems it does half of both by doing substring matching but only on the first instance it encounters, which is unexpected:

(venv) speedster@hoffman:/mnt$ dfc -p acre
FILESYSTEM              (=) USED      FREE (-)  %USED AVAILABLE  TOTAL MOUNTED ON     
acre1                   [==================--]  86.5%      5.7T  42.0T /farm/acre1    
(venv) speedster@hoffman:/mnt$ df |grep acre
acre1                   45119552512 39009344512  6110208000  87% /farm/acre1
/dev/sdak1              15625875456 15623655424     2220032 100% /farm/acre2
/dev/sdao2               4883638272  4782704640   100933632  98% /farm/acre7
/dev/sdam2               1953463296  1806845952   146617344  93% /farm/acre3
/dev/sdap2                976745472   956641024    20104448  98% /farm/acre6
/dev/sdf2               15625859072  3976003584 11649855488  26% /farm/acre4
/dev/sdan1               5860519936  3721060352  2139459584  64% /farm/acre8
/dev/sdar1               5860519936  1806887296  4053632640  31% /farm/acre5
/dev/sdas1               3907014912  2869947264  1037067648  74% /farm/acre12
/dev/sdat1               3907014912      123648  3906891264   1% /farm/acre14

Ideally, it would be cool to get the substring search result of both device and mount path strings but if that's too complicated, matching only exact would be less confusing because it gives heart attack the way it's currently implemented ;)

[note: and if you do decide to implement full substring matching, number sort would be a nice cherry on top, but certainly not required 😀

Thanks for making such a wonderful console visual utility ! ⭐⭐⭐⭐⭐

-=dave

(venv) speedster@hoffman:/mnt$ dfc -v
dfc 3.1.1
(venv) speedster@hoffman:/mnt$ uname -a
Linux hoffman 5.4.106-1-pve #1 SMP PVE 5.4.106-1 (Fri, 19 Mar 2021 11:08:47 +0100) x86_64 GNU/Linux
@rolinh
Copy link
Owner

rolinh commented Apr 27, 2021

Hi Dave 👋

Thanks for making such a wonderful console visual utility ! ⭐⭐⭐⭐⭐

Thanks a lot, this means something to me!

The -p flag acts only on the file system name (ie the FILESYSTEM column) and not on the mount point. In your example, there seems to be only one file system name that starts with acre1 although several mount points seem to match. I guess this is where the confusion stems from. I'm not sure yet if it would be best to have -p apply to the mount points as well or introduce a new flag but I'd tend to favor the latter to not break the existing behavior that some users might expect at this point.

@fiveangle
Copy link
Author

Thanks for responding @rolinh ! I see your point now... ZFS normalizes the block device name to match the zpool name, which is inherently chosen by a human, just as the mount path, so I completely missed how it had matched that in the FILESYSTEM column. That column contains what most would call the block "device" rather than the "filesystem" so that's where my confusion stemmed from reviewing the man page.

To keep things working as expected for everyone who has integrated dfc into their workflows, perhaps a new switch like -P (for P(ath) that allows substring search on the mount paths only rather than change the current -p behavior ? The mount point is the more human-facing aspect that I would imagine most are even more interested in keying off of than of the block device name, so I'm surprised no one has suggested this before :)

A new proof-of-space/time cryptocurrency has launched recently, requiring the management of filling up hard drives with large cryptographically generated files, and the dozens I've turned onto dfc (which is ideal for this situation) have all showered praise on it. Thanks again for this great work ! ❤️

@fiveangle
Copy link
Author

btw- we all wrap it in a while true; do dfc -d -t exfat -s mount; sleep 10; done loop to keep a realtime listing of usable space available where we can fill. Having this feature builtin via ansi terminal updates might be a really useful feature, but regardless it's working beautifully !

dfc

@rolinh
Copy link
Owner

rolinh commented Apr 27, 2021

To keep things working as expected for everyone who has integrated dfc into their workflows, perhaps a new switch like -P (for P(ath) that allows substring search on the mount paths only rather than change the current -p behavior ?

This sounds like a good option to me! I'm unsure when I'll have time to work on it though. PRs always welcome ;)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants