Re: loop-AES with ReiserFS for file-backed loop?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Anon wrote:
> Hello,  
>   
> According to loop-AES.README section 2.2:  
> "Don't use a journaling file system on top of file backed loop device. [snip] With file backed  
> loop devices, correct write ordering may extend only to page cache (which resides in RAM) of  
> underlying file system. VM can write such pages to disk in any order it wishes, and thus break  
> write order expectation of journaling file system."  
>   
> What if I use the ReiserFS file system with the 2.6 kernel and the "nolog" mount option to disable  
> journaling as described at:  
> http://www.namesys.com/mount-options.html  
>   
> Could I then use ReiserFS on top of a file backed loop device?  

AFAIK/AFAICT this is a "should not" thing.

You can use a journaling file-system-loopdevice on a journaling-files-system.
I personally use a XFS-filesystem-in-loop on a reiserfs-partition because
an XFS-filesystem can be easily grown. (unmount/losetup -d, grow the file,
losetup/mount, xfs_growfs <mountpoint>, you are done. This way the
loop-file stays the smallest possible size)

BUT in case your computer breaks down while writing data the probability of
a damaged filesystem increases enourmously as the blocks of the data and
journal of the filesystem in the loop could be written to the disc-platter
in any order. So the directorys (changed at the time of breakdown) and/or
(especially) the journal (can be damaged/are plain garbage) with a much
higher probability after a breakdown.

IOW you practicaly "loose" the journaling feature (and this is exactly for
the "error"-case. Most of the time the journal is "useless" as it's only
use is for correcting errors after any kind of "mishap") and you SHOULD use
a filesystem with a good fsck-tool.

But appart from that i don't think there are any other problems.
I remember some rants about possibel deadlocks if you stack
journaling-filesystems and block-layers, but i say that a deadlocking
filesystem is simply buggy.

As long as you only read (with noatime) while breaking down or there aren't
any dirty-buffers (and nothing unprocessed in the log) while breaking
down,the filesystem shouldn't get any more damaged by a breakdown than any
other filesystem directly on a block-device.

So as long as your computer doesn't break down you shouldn't have any
problems at all. :-)




-- 
Real Programmers consider "what you see is what you get" to be just as
bad a concept in Text Editors as it is in women. No, the Real Programmer
wants a "you asked for it, you got it" text editor -- complicated,
cryptic, powerful, unforgiving, dangerous.


-
Linux-crypto:  cryptography in and on the Linux system
Archive:       http://mail.nl.linux.org/linux-crypto/


[Index of Archives]     [Kernel]     [Linux Crypto]     [Gnu Crypto]     [Gnu Classpath]     [Netfilter]     [Bugtraq]
  Powered by Linux