Gordan Bobic wrote:
Hi,
Hello.
It's been a while since I last tried reiser4, and having just looked
at the wiki, I couldn't find any info at all on the cryptocompress
plugin and tail packing options at mkfs time specifically relating to
reiser4.
mkfs.reiser4 -l:
compression modes (works "per file"):
"latt" (id:0x1 type:0xd) ['Check on dynamic lattice'
compression mode plugin.]
If logical cluster in incompressible, then switch compression off and
check every
K-th cluster, where K dynamically increased to 32 on every non-success after
compression. If cluster is compressible, than K is set back to 1, etc..
"ultim" (id:0x2 type:0xd) ['Check ultimately' compression
mode plugin.]
Switch compression off forever after the first case of non-success.
"force" (id:0x3 type:0xd) ['Compress evrything' compression
mode plugin.]
Force to compress everything.
"conv" (id:0x4 type:0xd) ['Convert to extent' compression
mode plugin.]
If the first logical cluster of the file is incompressible, then switch
compression off forever.
This is default mode, but it works not good on various media-files..
Also, is there a nolog option on reiser4 as there is on reiserfs?
no sorry, currently reiser4 transaction manager can not be switched off.
The reason I ask is because I am looking for a file system that
improves on ext2 for very slow writing flash media (think cheap USB
sticks, SD cards, etc.). So, ideally, I want to disable journalling
and enable compression, to minimize the number of writing to the
underlying media. In theory, compression with journalling switched off
should give reiser4 an edge in this use-case, so I just wanted to
check what the current state of the compression is (couldn't find any
references to -o create=ccreg40 in the wiki), and that it works as one
might expect (compressing before committing to disk).
Works stable as expected (i.e. compression "on commits")
Another question (not sure if it is specifically related to reiser4 or
generic) is about compressed hard-linked DLLs and mmap. Specifically,
if a .so is hard-linked in two places, dynamically linking to each
instance causes both to be mmapped to the same memory since they'll
have the same inode, and that means the memory is only used once. How
does this work if the .so is compressed? Does it all still work the
same, with the decompressed file being in a single mmap for both
dynamically linked instances?
Works as usual: when populating address space by readpage(s) data are
read from disk and decompressed.
If page gets dirty, then its data will be compressed in flush time and
written to disk.
Many thanks.
You are welcome,
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
