Skip to contentSkip to conversation

users Digest, Vol 38, Issue 14

DISCUSSION Dipl.-Ing. Michael Niederle 2 participants 2 messages May 15, 2009 – May 17, 2009 2 messages not in the archive NILFS2 filesystem

lore
Share & tools
lore

A message that is not in the archive (sent off-list or not yet received): [email protected]

A message that is not in the archive (sent off-list or not yet received): mailman.1.1242356401.18832.users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org

#2 lore raw

Hi, Ryusuke!

Quoted 1 line

BTW, could you try switching IO scheduler to "noop" ?

I'm already using the NOOP-scheduler.

The nilfs is the root file system of my life-system. The two crashes occured before I converted a checkpoint to a snapshot. At the time the data losses occured there existed only checkpoints. I don't know whether this could matter or not.

Quoted 1 line

What is your pendrive product?

I have several pen drives for testing (from Corsair, OCZ, SanDisk). I'm currently testing nilfs on a "SanDisk Curzer Contour (16GB)". Initially I used kernel 2.6.30rc4, but switched to rc5 recently. The new kernel was build under nilfs - quickly and without any problems.

The problem of a pen based Linux system is, that it is more likely to be just disconnected instead of beeing shutdown cleanly than a desktop system.

Loosing current data will be no problem. Loosing the whole filesystem is a big problem ...

Greetings, Michael

#3 lore raw

Hi,

Quoted 7 lines · Dipl.-Ing. Michael Niederle

Hi, Ryusuke!

Quoted 1 line

What is your pendrive product?

I have several pen drives for testing (from Corsair, OCZ, SanDisk). I'm currently testing nilfs on a "SanDisk Curzer Contour (16GB)". Initially I used kernel 2.6.30rc4, but switched to rc5 recently. The new kernel was build under nilfs - quickly and without any problems.

I got a SanDisk Cruzer for tests today.
So far, it works pretty well with nilfs.

Quoted 7 lines

The problem of a pen based Linux system is, that it is more likely to be just disconnected instead of beeing shutdown cleanly than a desktop system.

Loosing current data will be no problem. Loosing the whole filesystem is a big problem ...

Greetings, Michael

If you have a chance, please apply the following patch.

It issues I/O request with an unplug option at the end of every segment. This may have effect of minimizing write order reversal causing the mount failures.

The patch is against 2.6.30-rc6 (ignore hunks since I'm managing more patches).

Also, I pushed a variant of the patch to the (standalone) nilfs2-module git tree, but this option is not supported for kernel-2.6.28 and the prior versions.

Cheers,
Ryusuke Konishi
--
From: Ryusuke Konishi <[email protected]>

nilfs2: set bio unplug flag for the last bio in segment

This sets BIO_RW_UNPLUG flag on the last bio of each segment during write. The last bio should be unplugged immediately because the caller waits for the completion after the submission.

---
 fs/nilfs2/segbuf.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)
fs/nilfs2/segbuf.c +1 -1
index dc0277a..9e3fe17 100644
@@ -393,7 +393,7 @@ int nilfs_segbuf_write(struct nilfs_segment_buffer *segbuf,
 		 * Last BIO is always sent through the following
 		 * submission.
 		 */
-		rw |= (1 << BIO_RW_SYNCIO);
+		rw |= (1 << BIO_RW_SYNCIO) | (1 << BIO_RW_UNPLUG);
 		res = nilfs_submit_seg_bio(wi, rw);
 		if (unlikely(res))
 			goto failed_bio;
Signature · 1 line
1.6.2