bcache vs enhanceio?
Hi
Seems old flashcache and the new enhanceio can add flash drives on the run, while bcache needs the filsystem to be built with them.
What is the future of bcache in this setting?
Signature · 11 lines
Vennlige hilsener / Best regards roy -- Roy Sigurd Karlsbakk (+47) 98013356 [email protected] http://blogg.karlsbakk.net/ GPG Public key: http://karlsbakk.net/roysigurdkarlsbakk.pubkey.txt -- I all pedagogikk er det essensielt at pensum presenteres intelligibelt. Det er et elementært imperativ for alle pedagoger å unngå eksessiv anvendelse av idiomer med xenotyp etymologi. I de fleste tilfeller eksisterer adekvate og relevante synonymer på norsk.
Hi Roy,
This is by design, and minimizes the potential for data corruption.
If you have a backing device with an existing filesystem, and are caching this in writeback mode, then reboot the system and the cache device does not come up, the backing device could still come up and could potentially be out of sync with the writes that were buffered to the cache device.
With bcache in writeback mode, if it cannot attach the cache device it will not register the backing device.
I am sure Kent will provide a much better answer than I have :)
Regards,
Andrew
Quoted 6 lines · Roy Sigurd Karlsbakk
Hi
Seems old flashcache and the new enhanceio can add flash drives on the run, while bcache needs the filsystem to be built with them.
What is the future of bcache in this setting?
A message that is not in the archive (sent off-list or not yet received): 5114334D.7040709-3e6jenk95VYpDvLZ8AWkcaVXKuFTiq87@public.gmane.org
Wouldn't it be better to allow the sysadmin to determine the safety?
Also, if running in writethrough, why shouldn't an SSD be allowed to be added in realtime?
All of this works well with systems like ZFS. I really don't see a reason for a filesystem being created to allow caching
roy
----- Opprinnelig melding -----
Quoted 34 lines
Hi Roy,
This is by design, and minimizes the potential for data corruption.
If you have a backing device with an existing filesystem, and are caching this in writeback mode, then reboot the system and the cache device does not come up, the backing device could still come up and could potentially be out of sync with the writes that were buffered to the cache device.
With bcache in writeback mode, if it cannot attach the cache device it will not register the backing device.
I am sure Kent will provide a much better answer than I have :)
Regards,
Andrew
Quoted 7 lines · Roy Sigurd Karlsbakk
Hi
Seems old flashcache and the new enhanceio can add flash drives on the run, while bcache needs the filsystem to be built with them.
What is the future of bcache in this setting?
Signature · 11 lines
Vennlige hilsener / Best regards roy -- Roy Sigurd Karlsbakk (+47) 98013356 [email protected] http://blogg.karlsbakk.net/ GPG Public key: http://karlsbakk.net/roysigurdkarlsbakk.pubkey.txt -- I all pedagogikk er det essensielt at pensum presenteres intelligibelt. Det er et elementært imperativ for alle pedagoger å unngå eksessiv anvendelse av idiomer med xenotyp etymologi. I de fleste tilfeller eksisterer adekvate og relevante synonymer på norsk.
Quoted 1 line · Roy Sigurd Karlsbakk
Wouldn't it be better to allow the sysadmin to determine the safety?
The sysadmin can override, but - say you're using bcache for your root filesystem and after a reboot the SSD doesn't come up, for whatever reason.
How's the sysadmin supposed to know for sure whether there was dirty data in the cache? There's no way to reliably track that without bcache tracking it itself in the backing device's superblock.
Say there wasn't any dirty data in the cache, so you can safely run without the cache device - so you do, so you can boot up and use your machine.
Then later you figure out what's wrong with the SSD (cable got unplugged?), so you reenable caching.
But the cache is now inconsistent - you _cannot_ use that cached data. With the backing device superblock, bcache can trivially note that the cache is out of sync and make sure that that cached data isn't used.
If we didn't have that, the sysadmin would have to make _sure_ to use the right flag when reattaching to specify cached data shouldn't be used, otherwise he just corrupted all his data.
Quoted 1 line
Also, if running in writethrough, why shouldn't an SSD be allowed to be added in realtime?
If you're running in writethrough, you'd already be caching... not sure what you mean?
Quoted 1 line
All of this works well with systems like ZFS. I really don't see a reason for a filesystem being created to allow caching
ZFS is a filesystem that also does caching, bcache isn't a filesystem. Did you get something backwards...?
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 18 lines · Kent Overstreet
Quoted 1 line · Roy Sigurd Karlsbakk
Wouldn't it be better to allow the sysadmin to determine the safety?
The sysadmin can override, but - say you're using bcache for your root filesystem and after a reboot the SSD doesn't come up, for whatever reason.
How's the sysadmin supposed to know for sure whether there was dirty data in the cache? There's no way to reliably track that without bcache tracking it itself in the backing device's superblock.
Say there wasn't any dirty data in the cache, so you can safely run without the cache device - so you do, so you can boot up and use your machine.
Then later you figure out what's wrong with the SSD (cable got unplugged?), so you reenable caching.
Quoted 7 lines
But the cache is now inconsistent - you _cannot_ use that cached data. With the backing device superblock, bcache can trivially note that the cache is out of sync and make sure that that cached data isn't used.
If we didn't have that, the sysadmin would have to make _sure_ to use the right flag when reattaching to specify cached data shouldn't be used, otherwise he just corrupted all his data.
Looking through the enhanceio repo it seems possible to do it without a superblock by utilizing customized udev rules.
Said rules prevent the backing device from being using to mount the root filesystem before the cache is attached.
Quoted 15 lines
Quoted 3 lines
Also, if running in writethrough, why shouldn't an SSD be allowed to be added in realtime?
If you're running in writethrough, you'd already be caching... not sure what you mean?
Quoted 1 line
All of this works well with systems like ZFS. I really don't see a reason for a filesystem being created to allow caching
ZFS is a filesystem that also does caching, bcache isn't a filesystem. Did you get something backwards...?
--
To unsubscribe from this list: send the line "unsubscribe linux-bcache" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Signature · 2 lines
CTO | Orion Virtualisation Solutions | www.orionvm.com.au Phone: 1300 56 99 52 | Mobile: 0428 754 846
A message that is not in the archive (sent off-list or not yet received): CAOzFzEiLeW=nvuwcrVrs2xO__92ze7b6BDt8MkAkaNctuSR9Vg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org
Quoted 4 lines
Looking through the enhanceio repo it seems possible to do it without a superblock by utilizing customized udev rules.
Said rules prevent the backing device from being using to mount the root filesystem before the cache is attached.
Just to folow up with the udev config mentioned:
https://github.com/stec-inc/EnhanceIO/tree/master/Documents
Signature · 2 lines
CTO | Orion Virtualisation Solutions | www.orionvm.com.au Phone: 1300 56 99 52 | Mobile: 0428 754 846
Quoted 4 lines
Quoted 4 lines
Quoted 2 lines
Also, if running in writethrough, why shouldn't an SSD be allowed to be added in realtime?
If you're running in writethrough, you'd already be caching... not sure what you mean?
Perhaps he means being restricted to only being able to add a write-through cache without the superblock prep? On a reboot or cache device fault event it would not cause any corruption, just performance impact back to where it was before the device was added.