[conspire] Safe NTFS read/write driver for Linux

[Eric De Mund]

Rick, Don, All,

Eric De Mund <ead at ixian.com>:
> What's the executive summary of what I need to know about journaling
> filesystems that significantly reduce corruption? 

Rick Moen <rick at linuxmafia.com>:
] Some corruption protection is one benefit; much, much shorter fsck
] times is the other.
]
] Executive summary: Journaling filesystems have, by now, long been the
] default on all Linux distros, and are highly advised except in rare
] circumstances. They protect against many lossage modes but you still
] need backup. Go with your distro's default choice of journaling file-
] system even if it's ReiserFS ;-> , and you're better off than without.

Eric De Mund <ead at ixian.com>:
> In a couple of weeks I'm going to be installing a new Debian system
> and will choose one of these journaling filesystems.

Rick Moen <rick at linuxmafia.com>:
] Taking the path of least resistance, assuming you're creating new
] filesystems, will result in your using ext3, which is fine. You can
] read more at the relevant links on
] <http://linuxmafia.com/kb/Filesystems/>.

Many thanks. I appreciate the time you took (and always take) to write
and illuminate things.

I don't have any ext2 filesystems to carry forward; my "notebase", an
informal database of some 20,000-25,000 technical notes, and a rolo file
is pretty much all I carry forward from one system to the next. So I'll
be running with ext3. Can it perform "live" fsck(8)ing a la ZFS?

See, this bit is what caught my eye on Don's posted link of
<http://zfs-on-fuse.blogspot.com/>:

     Friday, June 30, 2006
     Why ZFS is needed even in desktops and laptops

     [...]

     Now, even though I use a reliable journaling filesystem (XFS) in my
     Linux system, I like to do a filesystem consistency check once in a
     while (usually not less than once every 3 months), which can only
     happen in those rare times when I need (or want) to reboot. Today
     was one of those days.

     And here are the results: xfs_repair.txt. I ended up with 90 files
     and empty dirs in lost+found. Why did this happen? It could be a
     hardware problem - either the hard disk, the SATA cable, the SATA
     controller or even the power supply; or a software bug - either in
     the SATA driver, the XFS code or somewhere else in the Linux
     kernel.

     [...]

     This is one of the reasons I need ZFS. I don't want to lose or end
     up with misteriously corrupted files. I want to see how often data
     is corrupted. I want to see if corruption only happens after a
     reboot (which means it's a disk write cache flush problem), or if
     it happens while the system is running (I can't fsck XFS
     filesystems while they're being used). Of course, I want to do this
     in order to diagnose the problem and fix it.

     [...]

     posted by wizeman at 16:57 | 4 comments

If ext3 can perform an fsck(8) at other than boot-time, that would be
great. However, if this behavior and/or ZFS is experimental, I can still
run with ext3 for now and be patient for this feature to be supported by
ext3 or for ZFS to become non-experimental.

Cheers,
Eric
--
"No, Groucho is not my real name. I am breaking it in for a friend."
--Groucho Marx

Eric De Mund
email: <ead at ixian.com>