From: Edward Shishkin <edward.shishkin@gmail.com>
To: "Dušan Čolić" <dusanc@gmail.com>,
reiserfs-devel <reiserfs-devel@vger.kernel.org>,
"Ivan Shapovalov" <intelfx100@gmail.com>
Subject: Re: Reiser4 inclusion into staging tree
Date: Sun, 02 Nov 2014 23:19:14 +0100 [thread overview]
Message-ID: <5456ADE2.9060405@gmail.com> (raw)
In-Reply-To: <CADW=+3knfdvLiuFRNWdA5PQjq+fg-iC+D6NNqV9y8=vewig-hw@mail.gmail.com>
On 11/02/2014 10:09 AM, Dušan Čolić wrote:
> I've made a poll on forums.gentoo.org with a question:" What Reiser4
> needs for you to start using it?" and with these offered answers I got
> following results:
>
> http://forums.gentoo.org/viewtopic-t-1002726-postdays-0-postorder-asc-start-25.html
>
> Mainline inclusion
> 45%
> Encryption
> 0%
> Snapshots
> 0%
> Defrag
> 0%
> Performance
> 0%
> Subvolumes
> 0%
> Grub2 support
> 0%
> Something else
> 31%
> It's already perfect
> 4%
> I'd never use it
> 18%
>
>
> Something else were users that asked for checksums (we do that for
> ccreg40 partitions or files?
Currently a checksum (adler32) is appended at the end of compressed
logical cluster. If cluster is not compressed for some reasons, then
checksum is not appended.
Also we protect bitmap blocks by checksums.
> what about reg40? just sizes AFAIK?),
Data of files managed by unix-file plugin is not protected by checksums.
I think that data protection by checksums is a business of applications
(not of the file system).
It makes sense to protect formatted nodes of the storage tree.
We'll need a new node format (node41, or so), which includes a 32-bit
checksum, which is updated/checked at flush/jload time. If jload() finds
that check is not OK, then make the file system read-only and suggest
to fsck.
Edward.
> SSD
> support, fixing undeletable dir bug, long mount times (if the large
> partition is / does dont_load_bitmap have to be in boot options or it
> can be in /etc/fstab?)...
>
> Based on these results (even on a small portion of linux user base
> that's traditionally been positive about reiser4) I really think that
> taking Reiser4 to the staging tree could be the move that would show
> users that the R4 development has some goal and is not dying down and
> with that would come influx of new users/developers.
>
> Ofc this is just my wish as I don't have the knowlege or right to push
> it to staging but if there's anything you can think of that I can do
> to help (I have one extra machine just waiting for some R4 testing)
> please tell me.
>
> Thanks a lot for your great work
>
> Dushan
--
To unsubscribe from this list: send the line "unsubscribe reiserfs-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2014-11-02 22:19 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-02 9:09 Reiser4 inclusion into staging tree Dušan Čolić
2014-11-02 22:19 ` Edward Shishkin [this message]
2014-11-02 22:47 ` Edward Shishkin
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=5456ADE2.9060405@gmail.com \
--to=edward.shishkin@gmail.com \
--cc=dusanc@gmail.com \
--cc=intelfx100@gmail.com \
--cc=reiserfs-devel@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).