| Summary | Try to get actual block size of filesystem in command line quota driver |
| Queue | IMP |
| Queue Version | FRAMEWORK_3 |
| Type | Enhancement |
| State | Resolved |
| Priority | 1. Low |
| Owners | |
| Requester | eric.rostetter (at) physics (dot) utexas (dot) edu |
| Created | 08/29/2006 (6886 days ago) |
| Due | |
| Updated | 11/16/2006 (6807 days ago) |
| Assigned | |
| Resolved | 11/16/2006 (6807 days ago) |
| Milestone | |
| Patch | No |
State ⇒ Resolved
style. ;-)
Long answer: Yes, but in general in the real world, it has a better
chance of being
correct than a single hardcoded value... However, in either case (the
single value,
or trying to determine it) it _can_ get it wrong. So neither is a
perect solution.
State ⇒ Feedback
on a file system with the same block size like the mail storage file
system?
Priority ⇒ 1. Low
Type ⇒ Enhancement
Summary ⇒ Try to get actual block size of filesystem in command line quota driver
Queue ⇒ IMP
New Attachment: t.t
State ⇒ New
function to the command line quota driver to try to get the actual
device block size to use as a multiplier for the quota command,
defaulting back to the current 1024 value if it can't do it. Seems
reasonable to me, but I wanted to pass it by here for comments.
Feel free to commit it, or feel free to ask me to commit it (no
problem for me to do so).
I can create/commit the patch for HEAD too, though this is from FRAMEWORK_3.