On 03/02/2013 09:32 PM, Edward Shishkin wrote:
[...]
2) "Batch" discard - the filesystem discards all free blocks upon a
user's
request (when mounted).
In this "batch" case, the signaling is done through a FITRIM ioctl
on any file.
"Batch" mode:
Implementing it should be simple enough (if I'm making correct
assumptions
about how does reiser4 work): we can just lock the bitmap and walk
through it,
issuing a discard for each long enough free sequence.
Mmm, I haven't found definition of "free block"..
For example, we have deleted a file by unlink(2), and the transaction,
which contains the updated bitmap is not yet committed. And here is
an interesting question: at this moment blocks of that file are free, or
busy? ;)
[...]
Batched discard:
Some clarifications are needed to understand if we can implement
something useful here..
BTW, the indeterminacy of the notions "free/busy block" disappears, if we
translate everything to the language of transactions.
I think that in the batch mode we need to launch a process X, which does
something like this:
while (1) {
reiser4_init_context(); /* this opens a transaction */
for (i=0; i < BATCH_GRANULARITY; i++) {
get next bitmap block;
if (all bitmaps have been processed)
break;
/* at this point we do have a pointer to the atom */
scan the bitmap and insert all "free extents" to atom's
discard tree;
capture the bitmap;
make the bitmap dirty;
}
reiser4_exit_context(); /* this closes the transaction */
if (all bitmaps have been processed)
break;
}
In this case "batched" discard requests will be issued as "realtime"
ones when committing transactions spawned by the process X.
Problems:
1. Excess IOs of (artificially dirtied) bitmap blocks. But IMHO this
is a minor problem. We'll think how to avoid those IOs.
2. Bitmap block can be already captured by another process Y
(in other words, this bitmap block is contained in another atom).
One of the possible solutions is to close current transaction and
jump to the existing one (spawned by the process Y). That atom
may already contain a tree with "realtime discard extents". In this
case we just need to complement them with _all_ free extents of
the respective bitmap block (note, that the set of "realtime discard
extents" is a subset of free extents that we need to discard in
batch mode).
So, discard/TRIM support can be implemented in reiser4 as an
upgrade of transaction manager and block allocator. This upgrade
is backward and forward compatible.
The last thing is to make sure that fsck will be happy with the new
allocation policy (i.e. it won't perform massive reallocations, which
are useless for SSD). I am sure with 99.9%, that everything will be
OK here.
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
