I think snapraid status should be changed so that the output is the same as snapraid -v status.
The --verbose option for status is not really documented in the manual, and it only adds 5 extra lines of information to the status output. But they are useful lines of information. So it is better to just have snapraid status always report all of the information, regardless of whether the -v option is passed or not.
Last edit: jwill42 2014-10-20
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Then I hope you will be watching this forum more closely and responding to more of the questions that people have. Because that information is important to understand the problems that people have with SnapRAID that you have not responded to in the past. Saying that "users should not care about them" is only valid if you are able to fix the problems that users have that you have sometimes not responded to.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It's only a matter to decide how to present info to a typical user in the "status" command compared to the "status -v" one.
At least for me, when I run the status command, it's because I want to get general info about the array. Skipping internal details like number of blocks and parity size, it's just a way to avoid to confuse users presenting to much information.
When instead some problem arise, the -v option, and even more the -l one, are specifically intended to provide a more detailed view, that allows to understand better what happens.
Ciao,
Andrea
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I don't see how giving a count of files, hardlinks, symlinks, and empty directories is not part of a status report. That information is obviously an important part of the status of a SnapRAID volume. I think the number of blocks should also be a part of the status report, but I concede that is arguable.
However, all of that is beside the point. The philosophy of "users should not care about them" is in error for this project. It might be correct for a larger project that has people dedicated to providing customer support, but for this project, there is only you. Therefore, it makes sense to provide as much information as possible to users so that they can solve problems themselves, or so that they can post a detailed status report and get help from other users. That way, you do not have to provide customer support for all users by yourself, which obviously you do not have the time to do.
Last edit: jwill42 2014-10-25
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
By the way, the status report includes counts for "Fragmented files" and "Excess fragments", but I cannot find this documented anywhere. How are users supposed to understand what that means?
Also, as has been discussed in another thread, it is possible for the parity file to be larger than the size of the data drive with the largest number of blocks allocated (i.e., used + wasted). This can occur when users have deleted files which resulted in a "hole" in the parity file.
It would be useful if the status report gave information for this kind of wasted parity space, where the parity file is even larger than expected from looking at the used + wasted sizes.
Last edit: jwill42 2014-10-25
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think
snapraid statusshould be changed so that the output is the same assnapraid -v status.The --verbose option for status is not really documented in the manual, and it only adds 5 extra lines of information to the status output. But they are useful lines of information. So it is better to just have
snapraid statusalways report all of the information, regardless of whether the -v option is passed or not.Last edit: jwill42 2014-10-20
This seems like a great idea.
Hi,
At now I prefer to keep internal info of SnapRAID out of the normal status report. So, no info like number of blocks, or parity info.
Essentially, the users should not care about them. They should care about used, and free space in data disk.
Obviously, this is a very subjective matter, so it's difficult to make everyone happy :)
Ciao,
Andrea
Then I hope you will be watching this forum more closely and responding to more of the questions that people have. Because that information is important to understand the problems that people have with SnapRAID that you have not responded to in the past. Saying that "users should not care about them" is only valid if you are able to fix the problems that users have that you have sometimes not responded to.
Hi jwill42,
It's only a matter to decide how to present info to a typical user in the "status" command compared to the "status -v" one.
At least for me, when I run the status command, it's because I want to get general info about the array. Skipping internal details like number of blocks and parity size, it's just a way to avoid to confuse users presenting to much information.
When instead some problem arise, the -v option, and even more the -l one, are specifically intended to provide a more detailed view, that allows to understand better what happens.
Ciao,
Andrea
I don't see how giving a count of files, hardlinks, symlinks, and empty directories is not part of a status report. That information is obviously an important part of the status of a SnapRAID volume. I think the number of blocks should also be a part of the status report, but I concede that is arguable.
However, all of that is beside the point. The philosophy of "users should not care about them" is in error for this project. It might be correct for a larger project that has people dedicated to providing customer support, but for this project, there is only you. Therefore, it makes sense to provide as much information as possible to users so that they can solve problems themselves, or so that they can post a detailed status report and get help from other users. That way, you do not have to provide customer support for all users by yourself, which obviously you do not have the time to do.
Last edit: jwill42 2014-10-25
By the way, the status report includes counts for "Fragmented files" and "Excess fragments", but I cannot find this documented anywhere. How are users supposed to understand what that means?
Also, as has been discussed in another thread, it is possible for the parity file to be larger than the size of the data drive with the largest number of blocks allocated (i.e., used + wasted). This can occur when users have deleted files which resulted in a "hole" in the parity file.
It would be useful if the status report gave information for this kind of wasted parity space, where the parity file is even larger than expected from looking at the used + wasted sizes.
Last edit: jwill42 2014-10-25
I think that with the new status in v7 this request becomes mostly irrelevant.
On Sat, Oct 25, 2014 at 1:14 PM, Leifi Plomeros mrleifi@users.sf.net wrote:
That would be incorrect. It is at most 20% irrelevant, since of the 5
lines, only 1 of them is related to the changes you are referring to.