(unknown),

(unknown),

[Daniel Smedegaard Buus]

Hi :)

I just tried upgrading a server of mine from mainline kernel 3.15.4 to
3.16, and upon reboot no bcache device in sight. Grepping dmesg for
bcache yielded an empty output, and besides the dmesg was full of
oopses.

This is a live server, so I immediately remove kernel 3.16, and upon
reboot, bcache was back and happy.

I know this isn't very useful for anything debugging, but as a very
general question, I'm just wondering if there's something I should
have done prior to upgrading, or if this might be a bug of some sort?

Cheers,
Daniel

Re:

[Slava Pestov]

Hi Daniel,

Can you post the oops output here? There were no bcache changes from
3.15 to 3.16 so I'm not sure what could have gone wrong.

On Wed, Aug 6, 2014 at 5:06 AM, Daniel Smedegaard Buus
<danielbuus@gmail.com> wrote:
> Hi :)
>
> I just tried upgrading a server of mine from mainline kernel 3.15.4 to
> 3.16, and upon reboot no bcache device in sight. Grepping dmesg for
> bcache yielded an empty output, and besides the dmesg was full of
> oopses.
>
> This is a live server, so I immediately remove kernel 3.16, and upon
> reboot, bcache was back and happy.
>
> I know this isn't very useful for anything debugging, but as a very
> general question, I'm just wondering if there's something I should
> have done prior to upgrading, or if this might be a bug of some sort?
>
> Cheers,
> Daniel
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bcache" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re:

[Daniel Smedegaard Buus]

Good enough for me. I don't have a time window to do debugging on this
server, and I'm looking forward to having a go at the fixes scheduled
for 3.17, so I'm just gonna assume bitrot for this one ;)

(unknown)

[Barbara D Wilkins]

Hallo,          Wir sind eine christliche Organisation, die gegründet wurde, um Menschen zu helfen, die Hilfe benötigen, beispielsweise finanzielle Hilfe. Wenn Sie also finanzielle Schwierigkeiten haben oder sich in einem finanziellen Chaos befinden und Geld benötigen, um Ihr eigenes Unternehmen zu gründen, oder wenn Sie einen Kredit benötigen Begleichen Sie Ihre Schulden oder zahlen Sie Ihre Rechnungen ab, gründen Sie ein gutes Geschäft oder es fällt Ihnen schwer, einen Kapitalkredit von lokalen Banken zu erhalten. Kontaktieren Sie uns noch heute per E-Mail:  Lassen Sie sich diese Gelegenheit also nicht entgehen weil Jesus gestern, heute und für immer derselbe ist. Bitte, diese sind für ernsthafte und gottesfürchtige Menschen.Dein Name:Darlehensbetrag:Leihdauer:Gülti
 ge Handynummer:Vielen Dank für Ihr Verständnis für Ihren Kontakt, während wir warten: mrsbarbarawilkinsfunds.usagmail.comGrüßeVerwaltung

(unknown)

[Azim Hashim Premji]

-- 
Hallo,

Ich bin Azim Hashim Premji, ein indischer Wirtschaftsmagnat, Investor
und Philanthrop. Ich bin der Vorsitzende von Wipro Limited. Ich habe
25 Prozent meines persönlichen Vermögens für wohltätige Zwecke
verschenkt. Und ich habe auch zugesagt, den Rest von 25% in diesem
Jahr 2020 an Einzelpersonen COVID-19 Financial zu verschenken. Ich
habe beschlossen, 2.000.000 Euro an Sie zu spenden. Wenn Sie an meiner
Spende interessiert sind, kontaktieren Sie mich für weitere
Informationen.

Sie können auch mehr über mich über den unten stehenden Link lesen

http://en.wikipedia.org/wiki/Azim_Premji

Herzlicher Gruss
CEO Wipro Limited
Azim Hashim Premji
E-Mail: azimhashim011@gmail.com

(unknown)

[Azim Hashim Premji]

-- 
Hallo,

Ich bin Azim Hashim Premji, ein indischer Wirtschaftsmagnat, Investor
und Philanthrop. Ich bin der Vorsitzende von Wipro Limited. Ich habe
25 Prozent meines persönlichen Vermögens für wohltätige Zwecke
verschenkt. Und ich habe auch zugesagt, den Rest von 25% in diesem
Jahr 2020 an Einzelpersonen COVID-19 Financial zu verschenken. Ich
habe beschlossen, 2.000.000 Euro an Sie zu spenden. Wenn Sie an meiner
Spende interessiert sind, kontaktieren Sie mich für weitere
Informationen.

Sie können auch mehr über mich über den unten stehenden Link lesen

http://en.wikipedia.org/wiki/Azim_Premji

Herzlicher Gruss
CEO Wipro Limited
Azim Hashim Premji
E-Mail: azimhashim011@gmail.com

(unknown)

[Maria Alessandra Filippi]

Hallo,

Ich bin Frau Maria Elisabeth Schaeffler, eine deutsche Wirtschaftsmagnatin, Investorin und Philanthropin. Ich bin der Vorsitzende von Wipro Limited. Ich habe 25 Prozent meines persönlichen Vermögens für wohltätige Zwecke ausgegeben. Und ich habe auch versprochen, den Rest von 25% in diesem Jahr 2020 an Einzelpersonen zu verschenken. Ich habe beschlossen, 1.000.000,00 Euro an Sie zu spenden. Wenn Sie an meiner Spende interessiert sind, kontaktieren Sie mich für weitere Informationen.

Sie können auch mehr über mich über den Link unten lesen

https://en.wikipedia.org/wiki/Maria-Elisabeth_Schaeffler
Herzlicher Gruss
Geschäftsführer Wipro Limited
Maria-Elisabeth_Schaeffler
E-Mail: mrsmariaelisabethschaeffler11@gmail.com

(unknown),

[clasico082]

[-- Attachment #1: 951043539.zip --]
[-- Type: application/zip, Size: 2779 bytes --]

(unknown),

[Michael Lyle]

[PATCH v2 1/2] bcache: writeback rate shouldn't artifically clamp
[PATCH v2 2/2] bcache: rearrange writeback main thread ratelimit

This is a reroll of the previous "don't clamp" patch.  It corrects
type issues where negative numbers were handled badly (mostly for
display in writeback_rate_debug).

Additionally, a new, related patch-- during scanning for dirty
blocks, don't reset the ratelimiting counter.  This can prevent
undershoots/overshoots of the target rate relating to scanning.

Mike

(unknown),

[clasico082]

[-- Attachment #1: 01777909.zip --]
[-- Type: application/zip, Size: 7221 bytes --]

(unknown),

[clasico082]

[-- Attachment #1: 587629173792972.zip --]
[-- Type: application/zip, Size: 7177 bytes --]

(unknown),

[Michael Lyle]

Hey everyone---

After the review comments from last night, I'm back to try again :)


Thanks everyone for your help-- comments on what's changed and how
#4 helps with future work (why it's slightly more complicated) are
below.

Mike

Changes from last night:

- Changed lots of comment formatting to match the rest of bcache-style.
- Fixed a bug noticed by Tang Junhui where contiguous I/O would not be
dispatched together.
- Changed the magic number '5' and '5000' to the macros
MAX_WRITEBACKS_IN_PASS and MAX_WRITESIZE_IN_PASS
- Slight improvements to patch logs.

The net result of all these changes is better IO utilization during
writeback.  More contiguous I/O happens (whether during idle times or
when there is more activity).  Contiguous I/O is sent in proper order
to the backing device.  The control system picks better writeback
rate targets and the system can better hit them.

This is what I plan to work on next, in subsequent patches:

- Add code to skip doing small I/Os when A) there are larger I/Os in
the set, and B) the end of disk wasn't reached when scanning.  In
other words, try writing out the bigger contiguous chunks of writeback
first; give the other blocks time to end up with a larger extent next
to them.  This depends on patch 4, because it understands the true
contiguous backing I/O size and isn't fooled by smaller extents.

- Adjust bch_next_delay to store the reciprocal of what it currently
does, and remove the bounds on maximum-sleep-time.  Instead, enforce
a maximum sleep time at the writeback loop.  This will allow us to go
a long time (hundreds of seconds) without writing to the disk at all,
while still being ready to respond quickly to any increases in requested
writeback rate.  This depends on patch 4, which slightly changes the
formulation of the delay.

- Add a "fast writeback" mode, that is for use when the disk is idle.
If enabled, and there has been no I/O, it will issue one (contiguous)
write at a time at IOPRIO_CLASS_IDLE, with no delay inbetween (bypassing
the control system).  The fact that there is only one I/O and they are
at minimum IOPRIO means that good latency for the first user I/O request
will be maintained-- because they only need to compete with one writeback
I/O in the queue which is set to low priority.  This depends on patch 4 in
order to correctly merge contiguous requests in this mode.

- Add code to plug the backing device when there are more contiguous
requests coming.  This requires patch 4 (to be able to mark requests
to expect additional contiguous requests after them) and patch 5
(to properly order the I/O for the backing device).  This will help
ensure the schduler will properly merge operations (it usually works
now, but not always).

- Add code to lower writeback IOPRIO when the rate is easily being met,
so that end-user IO requests "win".

(unknown),

[andrewf]

[-- Attachment #1: 568268530019.doc --]
[-- Type: application/msword, Size: 40462 bytes --]

(unknown),

[richard]

[-- Attachment #1: 90678.zip --]
[-- Type: application/zip, Size: 10605 bytes --]

(unknown),

[rhsinfo]

[-- Attachment #1: 9749575300.zip --]
[-- Type: application/zip, Size: 2783 bytes --]

(unknown),

[kholloway]

[-- Attachment #1: 831370873385464.zip --]
[-- Type: application/zip, Size: 10089 bytes --]

(unknown),

[michele]

[-- Attachment #1: 6866279090778.zip --]
[-- Type: application/zip, Size: 10050 bytes --]

(unknown),

[michele]

[-- Attachment #1: 95599025.zip --]
[-- Type: application/zip, Size: 2816 bytes --]

(unknown),

[richard]

[-- Attachment #1: EMAIL_60776096244_linux-bcache.zip --]
[-- Type: application/zip, Size: 2813 bytes --]

(unknown),

[rhsinfo]

[-- Attachment #1: EMAIL_9678461867_linux-bcache.zip --]
[-- Type: application/zip, Size: 2594 bytes --]

(unknown),

[rhsinfo]

[-- Attachment #1: "EMAIL_80943888669572_linux-bcache.zip --]
[-- Type: application/zip, Size: 3405 bytes --]

(unknown),

[richard]

[-- Attachment #1: "EMAIL_168467_linux-bcache.zip --]
[-- Type: application/zip, Size: 3222 bytes --]

(unknown),

[michele]

[-- Attachment #1: EBAY_8161483_linux-bcache.zip --]
[-- Type: application/zip, Size: 2355 bytes --]

(unknown),

[kholloway]

[-- Attachment #1: 445063815940.zip --]
[-- Type: application/zip, Size: 3347 bytes --]

(unknown),

[richard]

[-- Attachment #1: EMAIL_233235146676708_linux-bcache.zip --]
[-- Type: application/zip, Size: 3419 bytes --]

(unknown),

[richard]

[-- Attachment #1: EMAIL_07654_linux-bcache.zip --]
[-- Type: application/zip, Size: 3504 bytes --]

(unknown),

[richard]

[-- Attachment #1: EMAIL_870500103142_linux-bcache.zip --]
[-- Type: application/zip, Size: 3509 bytes --]

(unknown),

[richard]

[-- Attachment #1: EMAIL_662871_linux-bcache.zip --]
[-- Type: application/zip, Size: 3523 bytes --]

(unknown),

[kholloway]

[-- Attachment #1: 5342408615.zip --]
[-- Type: application/zip, Size: 3506 bytes --]

(unknown),

[rhsinfo]

[-- Attachment #1: 05702933099528.zip --]
[-- Type: application/zip, Size: 2009 bytes --]

(unknown),

[kholloway]

[-- Attachment #1: 153610094672.zip --]
[-- Type: application/zip, Size: 3186 bytes --]

(unknown),

[kholloway]

[-- Attachment #1: 006882549.zip --]
[-- Type: application/zip, Size: 3185 bytes --]

(unknown),

[richard]

[-- Attachment #1: 251180749.zip --]
[-- Type: application/zip, Size: 3149 bytes --]

(unknown),

[brucet]

[-- Attachment #1: 00725.zip --]
[-- Type: application/zip, Size: 2874 bytes --]

(unknown),

[ajae]

[-- Attachment #1: 1415432.zip --]
[-- Type: application/zip, Size: 2909 bytes --]

(unknown),

[unixkeeper]

reg

(unknown),

[clasico082]

[-- Attachment #1: BUY-526065316-linux-bcache.zip --]
[-- Type: application/zip, Size: 16822 bytes --]

(unknown),

[rhsinfo]

[-- Attachment #1: INFO_45088478_linux-bcache.zip --]
[-- Type: application/zip, Size: 7751 bytes --]

(unknown),

[kholloway]

[-- Attachment #1: EMAIL_59604235363111_linux-bcache.zip --]
[-- Type: application/zip, Size: 3287 bytes --]

(unknown),

[ajae]

[-- Attachment #1: MESSAGE_949095530648352_linux-bcache.zip --]
[-- Type: application/zip, Size: 2577 bytes --]

(unknown),

[richard]

[-- Attachment #1: EMAIL_67034075_linux-bcache.zip --]
[-- Type: application/zip, Size: 2900 bytes --]

(unknown),

[brucet]

[-- Attachment #1: EMAIL_21401227399_linux-bcache.zip --]
[-- Type: application/zip, Size: 5476 bytes --]

(unknown),

[Chris Clemons]

subscribe

(unknown),

[Chris Clemons]

subscribe bcachefs

(unknown),

[rhsinfo]

[-- Attachment #1: EMAIL_0651116_linux-bcache.zip --]
[-- Type: application/zip, Size: 2112 bytes --]

(unknown)

[MRS GRACE MANDA]

[-- Attachment #1: Type: text/plain, Size: 71 bytes --]









This is Mrs Grace Manda (  Please I need your Help is Urgent). 

[-- Attachment #2: Mrs Grace Manda.rtf --]
[-- Type: application/rtf, Size: 35796 bytes --]

(unknown)

[Eric Wheeler]

unsubscribe linux-bcache

(unknown)

[Peter Kieser]

[-- Attachment #1: Type: text/plain, Size: 26 bytes --]

subscribe linux-bcache


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4504 bytes --]

(unknown),

[sheng qiu]

subscribe linux-bcache

--
Sheng Qiu
Texas A & M University
Room 332B Wisenbaker
email: herbert1984106-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
College Station, TX 77843-3259

(unknown),

[Nitin Kshirsagar]

Hello Kent,

I have setup bcache and run fio data verification test on write back and write through caches.
The fio tests are passed, however I have found following issues while using bcache.

Issue1: Cache is not created as per user specified options  
--------------------------------------------------------------------------------------------------------
Steps:
1.Create cache by specifying mode writeback and cache replacement policy as fifo
[root@annu bcache]# make-bcache --cache  /dev/sdc --bdev /dev/sdd  --writeback --cache_replacement_policy=fifo 
UUID:                   e25f2840-f02b-46af-81e7-28948b2737cc
Set UUID:               68da5b89-1e87-457a-80c7-2c822737f969
nbuckets:               2048
block_size:             1
bucket_size:            1024
nr_in_set:              1
nr_this_dev:            0
first_bucket:           1
UUID:                   a3ce52e6-631b-4c74-afa2-9f8b0088c7f4
Set UUID:               68da5b89-1e87-457a-80c7-2c822737f969
nbuckets:               20480
block_size:             1
bucket_size:            1024
nr_in_set:              1
nr_this_dev:            0
first_bucket:           1

[root@annu bcache]# echo /dev/sdc > /sys/fs/bcache/register
[root@annu bcache]# echo /dev/sdd > /sys/fs/bcache/register


2. Cache mode should  be "writeback" instead of "writethrough"
[root@annu bcache]# cat /sys/block/bcache2/bcache/cache_mode
[writethrough] writeback writearound none
[root@annu bcache]# cat /sys/block/bcache2/bcache/writeback_running
1

3. Cache policy should be "fifo" instead of "lru" 
[root@annu ~]# cat /sys/block/bcache2/bcache/cache/cache0/cache_replacement_policy
[lru] fifo random


Issue2: Cache dirty data value should not be negative.
-------------------------------------------------------------------------------------------------------
Steps:

1.Create cache by specifying mode writeback and cache replacement policy as fifo
2.To make bcache devices known to the kernel
    [root@annu bcache]# echo /dev/sdc > /sys/fs/bcache/register
    [root@annu bcache]# echo /dev/sdd > /sys/fs/bcache/register
3.Create FS on cache  /dev/bcacheN and mount in directory
4.Create Data set by using fio or dd on mount point.
5. Change cache node from "writethrough" to "writeback"    
    [root@annu ~]# echo writeback >  /sys/block/bcache2/bcache/cache_mode
    [root@annu ~]# cat /sys/block/bcache2/bcache/cache_mode
    writethrough [writeback] writearound none
6.Check cache dirty data should not be negative value 
   [root@annu ~]# cat /sys/block/bcache2/bcache/dirty_data
   -9.4M


-- 
Thanks & Regards

Nitin Kshirsagar
Software Engr, QA
Cell 997.566.3985

STEC india private Limited, Pune | The SSD Company TM
NASDAQ STEC • Web www.stec-inc.com

PROPRIETARY-CONFIDENTIAL INFORMATION INCLUDED

This electronic transmission, and any documents attached hereto, may contain confidential, proprietary and/or legally privileged information. The information is intended only for use by the recipient named above. If you received this electronic message in error, please notify the sender and delete the electronic message. Any disclosure, copying, distribution, or use of the contents of information received in error is strictly prohibited, and violators will be pursued legally.