linux-ext4 - JBD commmit : Get list of all 'to be written' buffers in advance

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 12 May 2011 19:52:21 +0530
From:	Niraj Kulkarni <kulkarniniraj14@...il.com>
To:	linux-ext4@...r.kernel.org
Subject: JBD commmit : Get list of all 'to be written' buffers in advance

Hi all,
          I am trying to implement a concept called Transactional Flash 
(http://www.usenix.org/event/osdi08/tech/full_papers/prabhakaran/prabhakaran_html/) 

          in which all writes are flushed to disk (in this case Flash) 
as a circular linked list of pages. No journaling mechanisms are used.
           For that I am trying to get list of all buffers to be written 
(metadata or data) before actually writing them. I thought of 2 
approaches :

1. Get conservative list of all buffers before flushing any of them 
(before commit phase 2) in journal_commit_transaction function.
      Problem : Metadata writes use temporary buffers which are 
allocated just before write.

2. Instead of submitting buffers straightaway, collect all of them ( 
data + metadata ) and flush them in end.
      Problem :  i.   Possibility of blocking after data buffers are  
collected but before metadata buffer collection.
                            Since data buffers are locked, this may lead 
to deadlock. (I am not sure if it is spinlock)

                       ii.   Not able to differentiate between metadata 
buffers and Descriptor buffers.


Can anybody please help me in this regard?

Niraj
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html