can't get bache's sequential_cutoff to work
Hi,
maybe i missed something or maybe i'm just wrong.
# cat /sys/block/bcache2/bcache/sequential_cutoff 512k
# cat /sys/block/bcache2/bcache/stats_five_minute/bypassed 64.3M
# dd if=/dev/zero of=/mnt/bcache2/ttt bs=4M count=1000 oflag=direct 1000+0 records in 1000+0 records out 4194304000 bytes (4,2 GB) copied, 11,0348 s, 380 MB/s
# cat /sys/block/bcache2/bcache/stats_five_minute/bypassed 69.3M
I also see only IOP/s an writes go to the SSD but not to the disk behind. What's wrong?
Greets,
Stefan
A message that is not in the archive (sent off-list or not yet received): CA+res+Ti1-tGANkb9wRAgF4sAcUqEv9RfGjDvbdX3bbxS=XK8g@mail.gmail.com
A message that is not in the archive (sent off-list or not yet received): CA+res+Ti1-tGANkb9wRAgF4sAcUqEv9RfGjDvbdX3bbxS=XK8g-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org
It's 3.10 with bcache Updates from kent's for 3.10 branch.
Stefan
This mail was sent with my iPhone.
Am 23.07.2013 um 18:00 schrieb Jack Wang <[email protected] <mailto:[email protected]>>:
Quoted 43 lines
Hi Stefan,
Strange, I tested bcache 2 month ago, mostly bcache-3.2 branch in writeback mode, it works as claimed.
which kernel version are you using?
Jack
2013/7/23 Stefan Priebe - Profihost AG <s.priebe-2Lf/[email protected] <mailto:s.priebe-2Lf/[email protected]>>
Hi, maybe i missed something or maybe i'm just wrong. # cat /sys/block/bcache2/bcache/sequential_cutoff 512k # cat /sys/block/bcache2/bcache/stats_five_minute/bypassed 64.3M # dd if=/dev/zero of=/mnt/bcache2/ttt bs=4M count=1000 oflag=direct 1000+0 records in 1000+0 records out 4194304000 bytes (4,2 GB) copied, 11,0348 s, 380 MB/s # cat /sys/block/bcache2/bcache/stats_five_minute/bypassed 69.3M I also see only IOP/s an writes go to the SSD but not to the disk behind. What's wrong? Greets, Stefan -- To unsubscribe from this list: send the line "unsubscribe linux-bcache" in the body of a message to [email protected] <mailto:[email protected]> More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): 51EEDC73.5020101-2Lf/[email protected]
It works fine if do really small block writes like this:
# dd if=/dev/zero of=/dev/bcache0 bs=100 count=5000000
Can anybody tell me why?
Stefan
Am 23.07.2013 21:41, schrieb Stefan Priebe:
Quoted 54 lines
It's 3.10 with bcache Updates from kent's for 3.10 branch.
Stefan
This mail was sent with my iPhone.
Am 23.07.2013 um 18:00 schrieb Jack Wang <[email protected] <mailto:[email protected]>>:
Quoted 45 lines
Hi Stefan,
Strange, I tested bcache 2 month ago, mostly bcache-3.2 branch in writeback mode, it works as claimed.
which kernel version are you using?
Jack
2013/7/23 Stefan Priebe - Profihost AG <s.priebe-2Lf/[email protected] <mailto:s.priebe-2Lf/[email protected]>>
Hi, maybe i missed something or maybe i'm just wrong. # cat /sys/block/bcache2/bcache/sequential_cutoff 512k # cat /sys/block/bcache2/bcache/stats_five_minute/bypassed 64.3M # dd if=/dev/zero of=/mnt/bcache2/ttt bs=4M count=1000 oflag=direct 1000+0 records in 1000+0 records out 4194304000 bytes (4,2 GB) copied, 11,0348 s, 380 MB/s # cat /sys/block/bcache2/bcache/stats_five_minute/bypassed 69.3M I also see only IOP/s an writes go to the SSD but not to the disk behind. What's wrong? Greets, Stefan -- To unsubscribe from this list: send the line "unsubscribe linux-bcache" in the body of a message to [email protected] <mailto:[email protected]> More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): 51EEE805.7090200-2Lf/[email protected]
Mhm works directly on block device but not with XFS on top. Am 23.07.2013 22:31, schrieb Stefan Priebe:
Quoted 62 lines
It works fine if do really small block writes like this:
# dd if=/dev/zero of=/dev/bcache0 bs=100 count=5000000Can anybody tell me why?
Stefan
Am 23.07.2013 21:41, schrieb Stefan Priebe:Quoted 54 lines
It's 3.10 with bcache Updates from kent's for 3.10 branch.
Stefan
This mail was sent with my iPhone.
Am 23.07.2013 um 18:00 schrieb Jack Wang <[email protected] <mailto:[email protected]>>:
Quoted 45 lines
Hi Stefan,
Strange, I tested bcache 2 month ago, mostly bcache-3.2 branch in writeback mode, it works as claimed.
which kernel version are you using?
Jack
2013/7/23 Stefan Priebe - Profihost AG <s.priebe-2Lf/[email protected] <mailto:s.priebe-2Lf/[email protected]>>
Hi, maybe i missed something or maybe i'm just wrong. # cat /sys/block/bcache2/bcache/sequential_cutoff 512k # cat /sys/block/bcache2/bcache/stats_five_minute/bypassed 64.3M # dd if=/dev/zero of=/mnt/bcache2/ttt bs=4M count=1000 oflag=direct 1000+0 records in 1000+0 records out 4194304000 bytes (4,2 GB) copied, 11,0348 s, 380 MB/s # cat /sys/block/bcache2/bcache/stats_five_minute/bypassed 69.3M I also see only IOP/s an writes go to the SSD but not to the disk behind. What's wrong? Greets, Stefan -- To unsubscribe from this list: send the line "unsubscribe linux-bcache" in the body of a message to [email protected] <mailto:[email protected]> More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): 51EEE9D9.7090207-2Lf/[email protected]
Quoted 1 line · Stefan Priebe
Mhm works directly on block device but not with XFS on top.
That's odd...
Do you suppose you could look at what blktrace says is going down? If you could compare what blktrace says is going to the bcache device with and without XFS, hopefully that'll show what's going wrong...
Only thing I can think of that would cause it is for some reason XFS is sending bios down in the wrong order... which normally wouldn't be _too_ painful since both the elevator and the disk's cache will reorder the IOs, so I can see how that would slip by.
Am 25.07.2013 02:14, schrieb Kent Overstreet:
Quoted 5 lines · Stefan Priebe
Quoted 1 line
Mhm works directly on block device but not with XFS on top.
That's odd...
Quoted 8 lines
Do you suppose you could look at what blktrace says is going down? If you could compare what blktrace says is going to the bcache device with and without XFS, hopefully that'll show what's going wrong...
Only thing I can think of that would cause it is for some reason XFS is sending bios down in the wrong order... which normally wouldn't be _too_ painful since both the elevator and the disk's cache will reorder the IOs, so I can see how that would slip by.
Hi,
will try to have a look. But can it also be that the history of 128 entries is too small under my workload and bcache does not detect the sequence? Is there a way to try with a higher value like 1024?
Stefan