Where Reiser4 may break?

Where Reiser4 may break?

[mjt]

Hi

I was thinking about some potential problems.

Actually, Nikita and I had a discussion about the issues with
cross-architecture compatibility. It would apparently not be easy to
do, because block size equals page size in Reiser4.

Is this common with other file systems? I didn't get to ask that
question so to get an answer :)

Just when stuff like FireWire and USB hard drives are getting popular
and no-one should buy a PC laptop, this may become an issue for
PPC Linux users...

Then, the issues with small and large keys. Is there any need for two
sizes? Isn't it hazardous that some peoples' systems may cease to
function because of that? It seems larger keys are far superior...

Any performance issues, anything?

Thanks!

-- 
mjt

Re: Where Reiser4 may break?

[Vladimir Saveliev]

Hello

On Thu, 2004-05-27 at 00:44, Markus TÆrnqvist wrote:
> Hi
> 
> I was thinking about some potential problems.
> 
> Actually, Nikita and I had a discussion about the issues with
> cross-architecture compatibility. It would apparently not be easy to
> do, because block size equals page size in Reiser4.
> 
yes, now moving a hard drive with reiser4 between systems with different
page size is impossible. 

> Is this common with other file systems?

no

>  I didn't get to ask that
> question so to get an answer :)
> 
> Just when stuff like FireWire and USB hard drives are getting popular
> and no-one should buy a PC laptop, this may become an issue for
> PPC Linux users...
> 
> Then, the issues with small and large keys. Is there any need for two
> sizes? Isn't it hazardous that some peoples' systems may cease to
> function because of that? It seems larger keys are far superior...
> 

Both large and small keys should be supported such that user does not
have to care of compile option
It was made compile option because there was a desire to try it as fast
as possible.

> Any performance issues, anything?
> 
> Thanks!

Re: Where Reiser4 may break?

[mjt]

On Thu, May 27, 2004 at 01:00:05PM +0400, Vladimir Saveliev wrote:

>yes, now moving a hard drive with reiser4 between systems with different
>page size is impossible. 
>> Is this common with other file systems?
>no

Well, we'll see what the future brings in this.
I couldn't care less about architecture-compatibility, but then again,
I may start caring if the situation demands it :)

>Both large and small keys should be supported such that user does not
>have to care of compile option
>It was made compile option because there was a desire to try it as fast
>as possible.

This is good news.
Would the file system/kernel then decide which key size to use and
where? What is the logic?

Hope you get it working!

Thanks

-- 
mjt

Re: Where Reiser4 may break?

[Vladimir Saveliev]

On Thu, 2004-05-27 at 13:25, Markus TÆrnqvist wrote:
> On Thu, May 27, 2004 at 01:00:05PM +0400, Vladimir Saveliev wrote:
> 
> >yes, now moving a hard drive with reiser4 between systems with different
> >page size is impossible. 
> >> Is this common with other file systems?
> >no
> 
> Well, we'll see what the future brings in this.
> I couldn't care less about architecture-compatibility, but then again,
> I may start caring if the situation demands it :)
> 
> >Both large and small keys should be supported such that user does not
> >have to care of compile option
> >It was made compile option because there was a desire to try it as fast
> >as possible.
> 
> This is good news.
> Would the file system/kernel then decide which key size to use and
> where? What is the logic?
> 

IMHO: size of key should be selectable on mkfs.reiser4 time. Kernel on
mount should be able to detect key format

> Hope you get it working!
> 
> Thanks

Re: Where Reiser4 may break?

[David Masover]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Markus Törnqvist wrote:
[ ... ]
| Well, we'll see what the future brings in this.
| I couldn't care less about architecture-compatibility, but then again,
| I may start caring if the situation demands it :)

Do we gain any speed by not adding that compatibility?  If so, it should
be optional (mkfs/mount option, not compile time).  Maybe we should be
able to specify at mkfs time what architecture to optimize for (x86,
ppc, everything, etc.), but let it default to optimize for this one.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iQIVAwUBQLZd4ngHNmZLgCUhAQI+/w//eXFRJdpj9S3nGCv7dFB7MTNdkocib8Ys
JXph2dL0N7nO04WiVLkxFaAIYWmQVQ/pN9JTMX36PQVm8f/An5ltXJyb2516TZSy
rGxD+WR13uB26b6/c2CERT6yE93FHQAWFEgkJqtCsBYD2ICAIoa03qGdyWyefxQ5
Y3H7o340KIcOCzcNzDJvk66/VdZYG83KBaiMrg9fohPPV0d/gFbLSNguGJAHzh/B
TYAi5bucYPBCMRta5CpmccD721icDryrbHxibWxLdA7+ncJquCLb4zdBaeNLD3Qh
qoFxKxqvSZOwnXqCXKc2EgDT16a+bFOwj39xPynMeBXbuJrvVL0a70og7kGjMyf1
tRA4s7LflAMq0JldM/fRxbQb/RtCe2nxh5/p0V5wI2ZFWyilowYooZ3uWm4lqRWe
RPbCFxPeGuZqq782yhnln7iaPqrBK0PaaPqsBgousnacwQnfqaZl/D1QGqt03bUi
zR+hTvKbc1zv85f2LoprEA8HtdMXwzQH8AdK1E+0qW/bHI6EAGBtBXWE29QJDObe
mh0AZDstqcm9OiK75hEGPRPnjGs72S7TKwuX8eIk1kTxmiTQqvXsQmpGwWZOHRoD
z0qVFt0a3a9JQnMsC1UE6qpbxjK5oEzmj/l+MCiqQuobKm/oS6r1g0V0cVACCkg3
vE+bRcrGcDE=
=EIQc
-----END PGP SIGNATURE-----