# kernel cache forces me to add a sync

## toralf

In the collowing code sequence (to produce encrypted files) :

```
head -c $SPACE /dev/zero > $DIR/$FILE

losetup $LOOP $DIR/$FILE

badblocks -s -w -t random -v $LOOP

cryptsetup luksFormat -c aes-xts-plain -s 256 -y $LOOP

cryptsetup luksOpen $LOOP $FILE

mkfs.ext2 /dev/mapper/$FILE

sleep 1

cryptsetup luksClose $FILE

losetup -d $LOOP

```

 without the "sleep 1" I sometimes get an error for the luksClose command 

```
+ cryptsetup luksClose t

Device t is busy.

+ losetup -d /dev/loop0

loop: can't delete device /dev/loop0: Device or resource busy

```

I'm wondering whether this is usual or a bug (in kernel 3.2.0) ?Last edited by toralf on Tue Jan 10, 2012 12:49 pm; edited 1 time in total

----------

## roarinelk

just try "sync" instead of the sleep?

----------

## toralf

 *roarinelk wrote:*   

> just try "sync" instead of the sleep?

 good point.

Nevertheless - bug or feature ?

----------

## roarinelk

feature, of course :)  That's what caches are for, no? To hide the horrible latency and puny throughput of mass storage media

----------

## Hu

I agree that a cache hiding the latency of writing all the filesystem metadata is useful.  However, I am not sure whether it can be considered a feature that the cache causes the cryptsetup luksClose to fail.  IMO, it would be nicer if the luksClose operation blocked until either the I/O completes successfully or a fatal error occurs.

----------

