A best approach to get a summary of r4-conflicting kernel changes from 2.6.39

A best approach to get a summary of r4-conflicting kernel changes from 2.6.39

[Ivan Shapovalov]

Hello,

What is the best way to get some "summary" of changes that the kernel had 
undergone from 2.6.39 (last reiser4-compatible) to current? I need not all 
changes, but only those which make the current kernel reiser4-incompatible.
In particular, will "git log" suffice - and if yes, to which files/directories 
shall it be applied?

Thanks in advance,
Ivan Shapovalov

Re: A best approach to get a summary of r4-conflicting kernel changes from 2.6.39

[Edward Shishkin]

Hi Ivan,

Such summaries can be found at http://kernelnewbies.org/RecentChanges
(see section "VFS" of each summary).

Reiser4 makes a friendship with Linux VFS in all items except
fs-writeback. So I think it will be enough just to look at respective
changes, say, in ReiserFS (v3).

As to modifications in fs-writeback: Reiser4 has been adjusted to
3.1 stuff by Marcin Baczyński (I can forward the patch). I believe
this can be easily ported also to the next kernels.

Thanks,
Edward.
P.S.
Here I explained bits where reiser4 clashes with fs-writeback:
http://marc.info/?l=reiserfs-devel&m=132603099732236&w=2




On 08/17/2012 10:53 PM, Ivan Shapovalov wrote:
> Hello,
>
> What is the best way to get some "summary" of changes that the kernel had
> undergone from 2.6.39 (last reiser4-compatible) to current? I need not all
> changes, but only those which make the current kernel reiser4-incompatible.
> In particular, will "git log" suffice - and if yes, to which files/directories
> shall it be applied?
>
> Thanks in advance,
> Ivan Shapovalov
> --
> 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

--
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

Re: A best approach to get a summary of r4-conflicting kernel changes from 2.6.39

[dimas]

> As to modifications in fs-writeback: Reiser4 has been adjusted to
> 3.1 stuff by Marcin Baczyński (I can forward the patch). I believe
> this can be easily ported also to the next kernels.

sounds interesing. could you please give a link to that stuff?
--
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

Re: A best approach to get a summary of r4-conflicting kernel changes from 2.6.39

[Edward Shishkin]

On 09/09/2012 08:40 AM, Ivan Shapovalov wrote:
> On Sunday 09 September 2012 01:31:17 Edward Shishkin wrote:

[...]

>>> There is a less difficult problem. Reiser4 (in both file plugins)
>>> doesn't release a longterm lock when locking a page in ->readpages()
>>> and this violates reiser4 locking policy. Moreover, I am able to get
>>> the deadlock in practice in 4-5 hours of working under high workload.
>>>
>>> We need to release the longterm lock before acquiring a page lock,
>>
>> It seems I was wrong here:
>> I just looked at reiser4 locking policy: the longterm lock has
>> more higher priority than page lock, so we don't need to release it..
>> Sorry for the false alarm!
> No problem. (But why the deadlock occurs then?)


Interesting question. No ideas so far. Dump of processes is needed
to understand what they are waiting for..


>
> BTW, as far as I can see, there (in readpage_unix_file(), if I initially
> understood you correctly) is an inconsistency with VFS guidelines
> (Documentation/filesystems/vfs.txt). If we unlock page for some reasons - and
> we do that before calling find_file_item() - we shall not try to relock and then
> check if the page is still OK; instead, we shall return AOP_TRUNCATED_PAGE and
> we'll be called again with page relocked and intact.
> Is there any specific reason why we do not use this mechanism?


Also take a look at the comment to AOP_TRUNCATED_PAGE definition
(./include/linux/fs.h).

They (VFS folks) believe that unlocked page will be truncated by
another process. However, this is not necessarily, and it won't be
so in reiser4 because concurrent processes acquire (non)exclusive
access to a file (see get_[non]exclusive_access()):

->read(), which calls ->readpage(), takes non-exclusive access;
->write(), which calls ->readpage() for partial writes, takes
   exclusive access;
->mmap (which calls ->readpage()) takes exclusive access;
->truncate(), (which may truncate the page) takes exclusive access;
etc.

I think that this ancient documentation (vfs.txt) has been created
long time ago when file systems were primitive (minix, ext2, etc).
Nowadays modern file systems (like reiserfs, reiser4) perform
on-the-fly file conversions, which require additional locks held: we
need to make/implement decisions about the best form of data storage
basing on internal polymorphisms inherent to properly designed file
systems.

Thanks,
Edward.