From: Edward Shishkin <edward@namesys.com>
To: Linuxhippy <linuxhippy@web.de>, Jun OKAJIMA <okajima@digitalinfra.co.jp>
Cc: reiserfs-list@namesys.com
Subject: Re: one idea about reiser4 compress
Date: Thu, 14 Apr 2005 15:25:05 -0700 [thread overview]
Message-ID: <425EEDC0.2070707@namesys.com> (raw)
In-Reply-To: <425940FC.8060401@web.de>
Linuxhippy wrote:
> Hi Jun!
>
>> Assume you install a distribution on a compressed partition with
>> reiser4.
>> you usually do like this --
>>
>> | CD | Installer with decompression | -> | Re-compress with Reiser4 |
>> HDD |
>>
>> You dont think decompression -> recompression cycle is wasteful?
>> If CD contains compressed files with reiser4 compression format,
>> I guess it is possible to do like this --
>>
>> | CD with reiser4 compressed files | Installer | -> | HDD |
>> I mean, this eliminates an overhead of re-compression and make whole
>> isntall process simpler and faster. Maybe you could do install like
>> this --
>> # cp -a /mnt/cdrom /mnt/target_hdd
>> And this way would be much faster than usual installer today.
>>
>> How about this idea?
>>
>
Fine, but it makes sense only if source and target files are powered by
the same object plugin.
Also there is no any chances for 'cp' to implement this (who will inform
the file system if we
don't need to decompress?)
> To be honest I do not think your idea can be realized in a useful way
> because of:
> a.) Every Installer uses its own compression format, most time those
> packages have additional fines in it like install scripts and so on.
> b.) Reiser4.1 compression will eb definitivly optimized for speed,
> installer-packages are usually heavily optimized for size.
> c.) You would need new API's to archive this. Either through syscalls
> or via reiser's special files.
>
> Conclusion: It would be a major hassle to implement such stuff for
> next to null advantages. There are so many (important) features
> waiting to be implemented ;-)
Fast backup of cryptcompress files is a queued feature.
It should be a business of file reader/writer (not flush algorithm).
Also each cluster after compression is supposed
to be ciphered (not in 4.1), this means we need to copy iv-seed of
source file and store it in disk stat-data of target file
(I think to use object id as default iv-seed). This is a victim of fast
backup...
Edward.
next prev parent reply other threads:[~2005-04-14 22:25 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-04-07 9:03 testing compression in reiserfs4.1 mangoo
2005-04-07 13:06 ` Edward Shishkin
2005-04-10 13:38 ` one idea about reiser4 compress Jun OKAJIMA
2005-04-10 15:06 ` Linuxhippy
2005-04-10 17:25 ` David Masover
2005-04-10 20:10 ` Linuxhippy
2005-04-14 22:25 ` Edward Shishkin [this message]
2005-04-16 22:29 ` Jun OKAJIMA
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=425EEDC0.2070707@namesys.com \
--to=edward@namesys.com \
--cc=linuxhippy@web.de \
--cc=okajima@digitalinfra.co.jp \
--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.