- User Since
- Oct 24 2014, 7:17 PM (242 w, 3 d)
Fri, Jun 14
Wed, Jun 12
Has this been resolved / committed?
Has this been resolved / committed?
Fri, Jun 7
Tue, Jun 4
Tue, May 28
Mon, May 27
Sat, May 25
Fri, May 24
Tue, May 21
Mon, May 20
This change looks correct to me.
May 10 2019
May 6 2019
May 4 2019
May 3 2019
Apr 27 2019
A useful cleanup.
Apr 15 2019
Apr 13 2019
Apr 9 2019
Should this now be closed since it was resolved in D19811?
Mar 31 2019
Mar 29 2019
Mar 20 2019
Mar 17 2019
This seems like a very useful improvement.
Mar 16 2019
I would preface the actual condition "The nbp parameter is non-NULL when the mapping is for a block that contains data, one of an external data block, a direct block, or the final block in a chain of indirect blocks." before the correct clarification "If mapping an extended attribute block, nbp must point to a buffer for that block."
Mar 12 2019
Mar 11 2019
Mar 7 2019
Looks good, thanks for clarifying -f.
Mar 6 2019
Mar 3 2019
Your change looks good. I'll approve once you update the suggested mandoc refinement.
Mar 2 2019
Mar 1 2019
I recently added the new error EINTEGRITY which is intended for use when a cylinder group or other filesystem structure has an integrity error. My initial plan is to use it for check-hash failures, but this is another good place to use it. It means that the callers of the functions that return this error need to be prepared to handle it. Specifically when allocating blocks or files trying to allocate from a different cylinder group. When deleting blocks or files, not immediately giving up, but trying to release all the remaining blocks of the file. A similar analysis would need to be used for this error (notably trying to allocate from a different cylinder group).
The addition to fstab.5 is helpful, but slightly incomplete in that it is not clear in what context the update keyword would be used.I would add text at the end of your new block that says something like:
option is typically used in conjuction with two
file is used to set up the initial set of file systems.
file is then run to update the initial set of file systems and
to add additional file systems.
Feb 25 2019
Feb 19 2019
Jan 28 2019
Note that update of manual page date fell out on corrective update.
Jan 27 2019
As noted, date at top of manual pages needs to be updated (which I will admit, I failed to do when I added underscores).
Jan 26 2019
Jan 25 2019
Jan 17 2019
Jan 11 2019
Update the intro(2) manual page to better reflect the meaning as suggested by imp, cem, etal.
Jan 10 2019
At a minimum EINTEGRITY is useful for mount since it allows the mount command to notify the user that the mount failed because of an integrity error which very likely can be fixed with a run of fsck versus an I/O error which probably cannot.
Based on feedback from Ed Maste and Ed Schouten do not add EINTEGRITY to CloudABI. Rather map it to EINVAL as is done in Linux compatibility.
Jan 9 2019
It is useful to the application or user to distinguish EINTEGRITY from EIO. With EIO they know that the underlying media has failed and there is really nothing they can do. With EINTEGRITY the individual file has become corrupted, but if they still have its contents, they can remove it and rewrite it as the filesystem media itself is still working. Alternatively they can request the system administrator to run a check of the filesystem to attempt to clean up the file.
Mount is just one of the places that can return EINTEGRITY. It can also come back when accessing a file or directory whose meta information fails a check-hash.
Jan 8 2019
Update diffs based on reviewer comments:
gnn - corrections to File05 cddl/lib/libdtrace/errno.d
dim - drop unneeded changes to sanitizer, previously File14 and File15
Drop dteske as reviewer as gnn has reviewed the DTrace change
When a mount fails because of a hash-check failure it is helpful to get "Integrity check failed" rather than "Invalid Argument" back. There are numerous reasons that you can get "Invalid argument" including miss-typed disk or mount-point names and other administrative errors. Knowing that it was due to an integrity check gives a strong indication that a run of fsck is needed. Actually in the case of mount we have the ability to print a more complete message, but the low-level functions in the filesystems need to be able to return something other than EINVAL so that the mount-layer function can know how to formulate its error message.
Jan 7 2019
Jan 6 2019
Dec 30 2018
Dec 27 2018
This change now looks good to me.
Dec 21 2018
Dec 20 2018
Given that this plausibly works only with two different /etc/fstab files, I think your change should also include an update to the manual page to explain how the update keyword is intended to be used.
Dec 17 2018
This change does not seem wrong, though the only way I can see it being usable is to have the read-only mount's in /etc/fstab, then a special fstab that has the desired update mount lines in it. Because if the update mount's are in /etc/fstab, then for 'mount -a' the read-only mount will happen immediately followed by the read-write mount. Though I suppose that the update mount line could appear first (and fail) followed by the read-only mount which would presumably succeed. Then on the second 'mount -a' the update would succeed and the read-only would be skipped because it was already mounted. But this seems like a really obscure way of doing things. Plus you would have to change mount so that would not exit when the initial "ro,update" failed.