Re: [RFC] [PATCHv3 7/9] reiser4: batch discard support: actually implement the FITRIM ioctl handler.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 10/21/2014 08:11 PM, Ivan Shapovalov wrote:
On Tuesday 21 October 2014 at 20:01:55, Edward Shishkin wrote:	
On 10/21/2014 06:42 PM, Ivan Shapovalov wrote:
On Tuesday 21 October 2014 at 18:33:11, Edward Shishkin wrote:	
On 10/21/2014 06:23 PM, Ivan Shapovalov wrote:
On Tuesday 21 October 2014 at 18:21:56, Edward Shishkin wrote:	
[...]

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?
Sure. Please note that making reiser4_trim_fs's allocations BA_RESERVED will
not hinder this: delete_mutex is there for a reason.

Sure, and this is the reason, because when I hear "let's take a mutex",
I start to feel bad :)


I want to see explanation, why FITRIM ioclt can not finish the work when
there is no free space on disk.
Suppose we do not use reserved space for reiser4_trim_fs's allocations.
Let's analyze those two cases:

1. There is <= 5% free space on disk.
Initial grabbing fails, nothing can be trimmed.
This is wrong.

2. There is 5% + X (where X is some small number) free space on disk.
We can grab only X blocks at a time, so a total of ((SIZE * 5% / X) + 1)
transactions will be created. BTW, if X < erase unit, nothing can be trimmed.
This is ineffective.

Hope this makes sense.

This is already much better, thanks!
Then I should say that the whole idea to reserve % of free space is
incorrect.
Try to reserve 1% of total partition size with BA_CAN_COMMIT for an
iteration.
If it fails, then try to reserve 1 block with BA_CAN_COMMIT.
Hm? Both described cases are still broken.

In #1 (free space <= 5%) nothing changes; reiser4_trim_fs will never be able
to do its task without using reserved space.

In updated #2 (5% < free space < 6%), a transaction per every block (!)
will be created, and none of them will trim anything (1 block < erase unit).


If (5% < free_space < 5% + erase_unit), then fail with ENOSPC.
Why not? This is not the unlink case...
--
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




[Index of Archives]     [Linux File System Development]     [Linux BTRFS]     [Linux NFS]     [Linux Filesystems]     [Ext4 Filesystem]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite Forum]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Device Mapper]     [Linux Resources]

  Powered by Linux