On 10/21/2014 06:23 PM, Ivan Shapovalov wrote:
On Tuesday 21 October 2014 at 18:21:56, Edward Shishkin wrote:
On 10/21/2014 06:18 PM, Ivan Shapovalov wrote:
On Tuesday 21 October 2014 at 12:14:02, Edward Shishkin wrote:
On 10/21/2014 12:39 AM, Ivan Shapovalov wrote:
On Monday 20 October 2014 at 12:54:13, Edward Shishkin wrote:
On 08/17/2014 11:52 PM, Ivan Shapovalov wrote:
[...]
+ /*
+ * Grab some sane amount of space.
+ * We will allocate blocks until end of the partition or until
+ * the grabbed space is exhausted.
+ */
+ ret = reiser4_grab_reserved(super, 0, BA_CAN_COMMIT | BA_SOME_SPACE);
any "legitimate" user of the reserved space
will block on the mutex and eventually proceed. At the same time, given
a filesystem with (5% + eps) free space left, not using the reserved space
will result in trimming of (eps) blocks at a time.
reiser4_grab_reserved() grabs space from the reserved area (5%).
This is needed to make sure that unlink(), truncate(), etc. won't
fail, if there is no free space on disk. I don't think that FITRIM
ioctl needs this reserved area.
Well, IIUC, it doesn't hurt:
"doesn't hurt" is not enough. If you want to take a resource,
you should be going to explain, why do you need this.
I've explained the reason below... isn't it sufficient?
Sorry, but I don't see any explanation.
"given a filesystem with (5% + eps) free space left, not using the reserved
space will result in trimming of (eps) blocks at a time."
This is something that I am not able to parse :)
Ok, it is clear, why we can not fail with -ENOSPC when trying to delete
a file from a full partition, yes?
I want to see explanation, why FITRIM ioclt can not finish the work when
there is no free space on disk.
Thanks,
Edward.
--
To unsubscribe from this list: send the line "unsubscribe reiserfs-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
