On 01/07/2013 02:42 AM, Ivan Shapovalov wrote:
Hi again Edward,
Hello.
Here's what I want to try to do with reiser4 in meantime. I'd appreciate some
hints on that all...
So, first thing I'd like to implement is TRIM/discard support, both online
(via -o discard) and in a separate FITRIM ioctl().
That's just because I've got an SSD two days ago and thus now have to use in
rootfs some discard-aware fs like ext4.
I think it would be nice for beginning. Moreover, reiser4 still doesn't
have any setup optimal for SSD.
Unfortunately I don't have a ready proposal for TRIM/discard support in
reiser4.
I have ready proposals for the following features (they can be rather
complicated for the beginners though):
1) Repacker (On-line defragmentation);
2) Support of different transaction models:
a. pure journalling;
b. pure COW (Copy-On-Write);
c. smart (the current "mixed" one);
d. no transaction support (for people with UPSs);
3) Subvolumes (AKA "chunkfs");
4) Snapshots.
And then I want to do something with performance: sometimes during heavy I/O
to a slow /home storage (especially when it's multithreaded) many processes,
including the DE, just get stuck in "D" state and sit there for a minute or
two with load average of apx. 5.5 (on a hyperthreaded 2-core CPU).
and some process waits for fsync() completion?
For the first, I can look into other filesystems' implementations, but I'll
probably be unsure at which layer to put the actual discard call (in order not
to break reiser4's transactional nature).
If you decide to proceed with TRIM/discard support, you will need to
prepare the proposal by yourself. Let's start with some background,
that is:
. clarify underlying reasons (specific for SSD geometry?) of
TRIM/discard support: why do we need such support on the file
system layer;
. review of existing hardware and software means for such support;
. etc..
And yes, it would be nice to review existing TRIM/discard support
implementations in other file systems (say, ext4).
Once we figure out, what bits of reiser4 you should understand
perfectly to implement TRIM/discard support, I'll provide you with
respective hints.
And for the second, I just don't know why does that happen. Can it be due to
some r4-specific things/issues or that's just a horribly slow random access
speed of my hw?
Which hw? SSD?
I also remember complaints that umount (i.e. the final sync takes 2-3,
or even more minutes). It looks like in some cases reiser4 accumulates
too much dirty stuff..
It would be nice to periodically dump some info about atoms (current
number of all atoms, size of each atom, etc) to see the full picture of
their evolution during such freezing. I think, it makes sense to port
the old reiser4 profiling stuff, and populate it with more info (if
needed).
Also there is an oldest issue:
The following (old) benchmarks created with mongo(*) test suit show x2
advantage of reiser4 against reiserfs(v3) on CREATE phase (let's
consider only this phase for simplicity):
http://web.archive.org/web/20061113154648/http://www.namesys.com/benchmarks.html
I've made similar benchmarks with latest 2.6 kernels (sorry, lost the
results) and found that the advantage has disappeared (real time in
CREATE phase is the same as of reiserfs, or even worse). It shouldn't
be so: it indicates that something wrong is going on.. I remember
people complained on the performance drop in reiser4 long time ago, but
didn't have a chance to investigate this.
The straightforward way to narrow down the problem changeset is to
bisect starting from 2.6.8-mm2, the archives can be found here:
http://mirror.sit.wisc.edu/pub/linux/kernel/people/akpm/patches/2.6/
http://ftp.icm.edu.pl/packages/linux-reiserfs/reiser4-for-2.6/
http://mirror.sit.wisc.edu/pub/linux/kernel/people/edward/reiser4/reiser4-for-2.6/
However, it can be rather painful and requires a separate machine.
Thanks,
Edward.
(*)
http://sourceforge.net/projects/reiser4/files/reiser4-utils/bench-stress-tools/
--
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
