All of lore.kernel.org
 help / color / mirror / Atom feed
From: Edward Shishkin <edward@namesys.com>
To: Hans Reiser <reiser@namesys.com>
Cc: John Gilmore <jgilmore@glycou.com>, reiserfs-list@namesys.com
Subject: Re: Reiser4 documentation & specifically current status of repacker, compression, and semantics
Date: Wed, 26 Oct 2005 17:51:33 +0400	[thread overview]
Message-ID: <435F89E5.4000303@namesys.com> (raw)
In-Reply-To: <435EADEB.9090402@namesys.com>

Hans Reiser wrote:

>Edward Shishkin wrote:
>
>  
>
>>Hans Reiser wrote:
>>
>>    
>>
>>>John Gilmore wrote:
>>>
>>>      
>>>
>>>>So the first beta of compression will only have the option to
>>>>control it at mkfs time?
>>>>
>>>>  
>>>>        
>>>>
>>>It should be explained that on the first flush to disk of a new file the
>>>default compress plugin will test to see if the first 64k is
>>>compressable, and if it is not then it converts the file to a regular
>>>file plugin.
>>>
>>> 
>>>
>>>      
>>>
>>a little correction:
>>this is a compression transform plugin that is converted at flush
>>time, not file plugin
>>
>>    
>>
>Please define in more detail please.
>

http://www.namesys.com/cryptcompress_design.html
"Handling incompressible data"
and
http://www.namesys.com/cryptcompress-related_plugins.html
"Compression mode plugin"

>  Particularly, define whether large
>files that cannot be compressed get stored using extents and everything
>else that regular files use.
>
>  
>

Currently files powered by cryptcompress file plugin have its data 
stored only in the
items of CTAIL_ID

>Also, I thought we convert at first flush time, not at every flush
>time.  Did you write it to check at every flush? 
>

no, just turning off and no anymore check, but it can be easily changed

> Not entirely sure we
>want to do that for large multimedia files that are compressed by
>hardware, it could add a bunch of CPU, and I would think it would be
>more complex code, because now you have to convert extents, etc.
>

Yes, such converting seems to be a complicated workaround. We will need
something like "clustered extents"


>  I
>would be concerned that if you always have to check for compression with
>every little write to a file, the cost of that check will be substantial
>for many purposes.
>
>  
>

Since compression is going per cluster, we can consider a set of nominated
clusters as a pattern to check if we need to turn compression off[on] 
for the
whole file. Say, if the clusters of indexes #(N*k), k=0, 1, 2, ...  are
incompressible[compressible], then turn compression off[on].
The smaller N - the more substantial cost of check in the case when 
compression is off.

>Hans
>
>
>  
>

  reply	other threads:[~2005-10-26 13:51 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-10-23 18:50 Reiser4 documentation & specifically current status of repacker, compression, and semantics John Gilmore
2005-10-24 14:44 ` Edward Shishkin
2005-10-24 12:25   ` John Gilmore
2005-10-24 19:08     ` Edward Shishkin
2005-10-24 13:45       ` John Gilmore
2005-10-24 21:11         ` Hans Reiser
2005-10-25 19:06           ` Edward Shishkin
2005-10-25 22:12             ` Hans Reiser
2005-10-26 13:51               ` Edward Shishkin [this message]
2005-10-27 13:48                 ` Edward Shishkin
2005-10-24 19:03 ` Hans Reiser

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=435F89E5.4000303@namesys.com \
    --to=edward@namesys.com \
    --cc=jgilmore@glycou.com \
    --cc=reiser@namesys.com \
    --cc=reiserfs-list@namesys.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.