Re: Block Size for Windows

On 28/08/2012 23:43, Jonathan Tripathy wrote:

On 27/08/2012 20:55, Kent Overstreet wrote:

quoted

On Mon, Aug 27, 2012 at 12:43 PM, Jonathan Tripathy 
[off-list ref] wrote:

quoted

On 27/08/2012 20:22, Kent Overstreet wrote:

quoted

echo 1 > /sys/fs/bcache/<uuid>/unregister

echo 1 > /sys/block/bcache0/bcache/stop

Ok, so I managed to recreate everything with a block size of 512 bytes.
However, 2 bad things have happened:

1) In my Linux DomU, my fio randomwrite test have gone from about 
28k iops
to about 800 iops. Can this be fixed? changing bs and ba to 512 in 
the fio
config file didn't hep.

Ouch!

Bet the ssd doesn't like those 512 byte journal writes. I'm going to
have to think about that...

Hi Kent,

Ok, a little good news. I managed to sort out the low IOPS issue. When 
I formatted bcache0 with a 512 block size, I forgot to set the caching 
mode back to writeback. Once I did that, the IOPS were nice and high 
again (circa 26k IOPS). Sorry about the noise regarding that non-issue.

I re-tried the windows setup with writeback enabled for the 512B 
formatted cache. It kernel paniced as per-usual, however for some 
reason, it's kernel panicking upon every boot now, whereas when it was 
formatted with 4k sectors, once the system came back up, it was stable 
(until I tried another windows setup). The debug trace appears to be 
the same as the one I posted to the list (kernel BUG at fs/bio.c:420! 
invalid opcode: 0000 [#1] SMP).

I appreciate your time.

Thanks

I'm going to take a wild guess and say that my system is constantly 
throwing the same panic as there is some dirty data in the cache (that 
the windows setup has written) and when bcache tries to write this to 
the MD-RAID10 array, the kernel panics. Before when it only happened 
during windows setup, this was probably because I didn't have writeback 
enabled (or no cache setup at all), hence no dirty data.

To sum up my wild guess: The windows setup is writing certain data that 
is causing the MD-RAID10 array to panic the kernel.

But these are only guesses.