support for external persistent cache

I was wondering if it would be possible to add support for specifying a
device to use for read/write persistent cache. The reason why I'm
asking is because I see physical ram disks with battery backups
available recently. These ram disks are relatively cheap and could add
great performance for write through without the fear of data loss.

Any interest in adding support for this?
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: support for external persistent cache

i think that is a fileystem cache
not a md raid cache
i'm right?

2011/1/19 Cory Coager :
> I was wondering if it would be possible to add support for specifying=
a
> device to use for read/write persistent cache. =A0The reason why I'm =
asking is
> because I see physical ram disks with battery backups available recen=
tly.
> =A0These ram disks are relatively cheap and could add great performan=
ce for
> write through without the fear of data loss.
>
> Any interest in adding support for this?
> --
> To unsubscribe from this list: send the line "unsubscribe linux-raid"=
in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at =A0http://vger.kernel.org/majordomo-info.html
>



--=20
Roberto Spadim
Spadim Technology / SPAEmpresarial
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" i=
n
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: support for external persistent cache

reading again... should you use a good ups system with information
about % of batery, like a notebook?
read/write cache can be change with async or sync options on filesystem=
mount
batery support is done with ups system
maybe with some time of use (10 years) the baterry of you ramdisk
should be replaced, will you replace it? is easier replace a ups
batery or a ramdisk specific batery?
check at internet about 12vdc atx power supply, and use a charger and
a car batery to supply power to your computer, it's a very nice
solution =3D)


2011/1/19 Roberto Spadim :
> i think that is a fileystem cache
> not a md raid cache
> i'm right?
>
> 2011/1/19 Cory Coager :
>> I was wondering if it would be possible to add support for specifyin=
g a
>> device to use for read/write persistent cache. =A0The reason why I'm=
asking is
>> because I see physical ram disks with battery backups available rece=
ntly.
>> =A0These ram disks are relatively cheap and could add great performa=
nce for
>> write through without the fear of data loss.
>>
>> Any interest in adding support for this?
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-raid=
" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at =A0http://vger.kernel.org/majordomo-info.html
>>
>
>
>
> --
> Roberto Spadim
> Spadim Technology / SPAEmpresarial
>



--=20
Roberto Spadim
Spadim Technology / SPAEmpresarial
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" i=
n
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: support for external persistent cache

On 01/18/2011 10:17 PM, Roberto Spadim wrote:
> reading again... should you use a good ups system with information
> about % of batery, like a notebook?
> read/write cache can be change with async or sync options on filesystem mount
> batery support is done with ups system
> maybe with some time of use (10 years) the baterry of you ramdisk
> should be replaced, will you replace it? is easier replace a ups
> batery or a ramdisk specific batery?
> check at internet about 12vdc atx power supply, and use a charger and
> a car batery to supply power to your computer, it's a very nice
> solution =)
Sure, I'll replace the battery in the ram disk. Not much different than
a hardware raid card with a battery in it.

I think you're missing my point. A UPS isn't going to save your file
system if the machine dies mid-write.

--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: support for external persistent cache

ok,
but if you don=B4t sync file system (remove from memory and put in disk
controller)
you will lost information with or without a batery

how to don=B4t lose information?
don=B4t power down you memory,cpu, disk controller (sata controler, rai=
d
controller, or anyother) and disks (does it have a batery? a super
capacitor?)
if you power down, be sure that all memory was send to disk controller
and that disk controller have energy (batery or capacitor) to send
information to disks (they need batery or capacitor too)

right?
so, a ups can power cpu, memory, disk controller and disks with only
one batery (not a batery for each device cpu,memory,disk,disk
controller)
the best world could be a non volatile memory (250mb/s flash 4kb
block) with the speed of volatile memory (10000mb/s ddr3 i don=B4t know
the block size)


2011/1/19 Cory Coager :
> On 01/18/2011 10:17 PM, Roberto Spadim wrote:
>>
>> reading again... should you use a good ups system with information
>> about % of batery, like a notebook?
>> read/write cache can be change with async or sync options on filesys=
tem
>> mount
>> batery support is done with ups system
>> maybe with some time of use (10 years) the baterry of you ramdisk
>> should be replaced, will you replace it? is easier replace a ups
>> batery or a ramdisk specific batery?
>> check at internet about 12vdc atx power supply, and use a charger an=
d
>> a car batery to supply power to your computer, it's a very nice
>> solution =3D)
>
> Sure, I'll replace the battery in the ram disk. =A0Not much different=
than a
> hardware raid card with a battery in it.
>
> I think you're missing my point. =A0A UPS isn't going to save your fi=
le system
> if the machine dies mid-write.
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-raid"=
in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at =A0http://vger.kernel.org/majordomo-info.html
>



--=20
Roberto Spadim
Spadim Technology / SPAEmpresarial
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" i=
n
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: support for external persistent cache

On Wed, Jan 19, 2011 at 01:19:18PM -0200, Roberto Spadim wrote:
> ok,
> but if you don?t sync file system (remove from memory and put in disk
> controller)
> you will lost information with or without a batery
>
> how to don?t lose information?
> don?t power down you memory,cpu, disk controller (sata controler, raid
> controller, or anyother) and disks (does it have a batery? a super
> capacitor?)
> if you power down, be sure that all memory was send to disk controller
> and that disk controller have energy (batery or capacitor) to send
> information to disks (they need batery or capacitor too)
>
> right?
> so, a ups can power cpu, memory, disk controller and disks with only
> one batery (not a batery for each device cpu,memory,disk,disk
> controller)
> the best world could be a non volatile memory (250mb/s flash 4kb
> block) with the speed of volatile memory (10000mb/s ddr3 i don?t know
> the block size)

It would have to work the same as a hardware RAID controller.
Information is first written to the cache then synced to the
disk. If the data is in the cache but not on the disk, the
machine loses power, next boot up the software raid would need a
way to flush the data from the ram disk to the disk. Of course
this would require the battery be in working condition, as with
any hardware.

Hopefully I've explained that well enough. Perhaps it will be
better to see the hardware I'm talking about:
http://techreport.com/articles.x/16255
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: support for external persistent cache

ok, your hardware have:
cpu, memory, disk controller, disks

and you computer have:
cpu, memory, disk controler (your hardware)

if your computer cache don=B4t sync to your disk controller you will
lose information....

check that *memory, is the volatille memory and *disk controller is
the non volatille memory
if you tell me that you will never have a *memory, and you have always
a non volatille memory, no problem, you will never need a kernel
load... just a boot loader that read previous memory information and
start in that point... why don=B4t do this? non volatille memory is not
as fast as volatille memory
got the problem?


2011/1/19 Cory Coager :
> On Wed, Jan 19, 2011 at 01:19:18PM -0200, Roberto Spadim wrote:
>> ok,
>> but if you don?t sync file system (remove from memory and put in dis=
k
>> controller)
>> you will lost information with or without a batery
>>
>> how to don?t lose information?
>> don?t power down you memory,cpu, disk controller (sata controler, ra=
id
>> controller, or anyother) and disks (does it have a batery? a super
>> capacitor?)
>> if you power down, be sure that all memory was send to disk controll=
er
>> and that disk controller have energy (batery or capacitor) to send
>> information to disks (they need batery or capacitor too)
>>
>> right?
>> so, a ups can power cpu, memory, disk controller and disks with only
>> one batery (not a batery for each device cpu,memory,disk,disk
>> controller)
>> the best world could be a non volatile memory (250mb/s flash 4kb
>> block) with the speed of volatile memory (10000mb/s ddr3 i don?t kno=
w
>> the block size)
>
> It would have to work the same as a hardware RAID controller.
> Information is first written to the cache then synced to the
> disk. =A0If the data is in the cache but not on the disk, the
> machine loses power, next boot up the software raid would need a
> way to flush the data from the ram disk to the disk. =A0Of course
> this would require the battery be in working condition, as with
> any hardware.
>
> Hopefully I've explained that well enough. =A0Perhaps it will be
> better to see the hardware I'm talking about:
> http://techreport.com/articles.x/16255
> --
> To unsubscribe from this list: send the line "unsubscribe linux-raid"=
in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at =A0http://vger.kernel.org/majordomo-info.html
>



--=20
Roberto Spadim
Spadim Technology / SPAEmpresarial
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" i=
n
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: support for external persistent cache

don=B4t forget that you can use ramdisks.... just read how to select th=
e
right memory, and the right position before initialize you ramdisk

2011/1/19 Roberto Spadim :
> ok, your hardware have:
> cpu, memory, disk controller, disks
>
> and you computer have:
> cpu, memory, disk controler (your hardware)
>
> if your computer cache don=B4t sync to your disk controller you will
> lose information....
>
> check that *memory, is the volatille memory and *disk controller is
> the non volatille memory
> if you tell me that you will never have a *memory, and you have alway=
s
> a non volatille memory, no problem, you will never need a kernel
> load... just a boot loader that read previous memory information and
> start in that point... why don=B4t do this? non volatille memory is n=
ot
> as fast as volatille memory
> got the problem?
>
>
> 2011/1/19 Cory Coager :
>> On Wed, Jan 19, 2011 at 01:19:18PM -0200, Roberto Spadim wrote:
>>> ok,
>>> but if you don?t sync file system (remove from memory and put in di=
sk
>>> controller)
>>> you will lost information with or without a batery
>>>
>>> how to don?t lose information?
>>> don?t power down you memory,cpu, disk controller (sata controler, r=
aid
>>> controller, or anyother) and disks (does it have a batery? a super
>>> capacitor?)
>>> if you power down, be sure that all memory was send to disk control=
ler
>>> and that disk controller have energy (batery or capacitor) to send
>>> information to disks (they need batery or capacitor too)
>>>
>>> right?
>>> so, a ups can power cpu, memory, disk controller and disks with onl=
y
>>> one batery (not a batery for each device cpu,memory,disk,disk
>>> controller)
>>> the best world could be a non volatile memory (250mb/s flash 4kb
>>> block) with the speed of volatile memory (10000mb/s ddr3 i don?t kn=
ow
>>> the block size)
>>
>> It would have to work the same as a hardware RAID controller.
>> Information is first written to the cache then synced to the
>> disk. =A0If the data is in the cache but not on the disk, the
>> machine loses power, next boot up the software raid would need a
>> way to flush the data from the ram disk to the disk. =A0Of course
>> this would require the battery be in working condition, as with
>> any hardware.
>>
>> Hopefully I've explained that well enough. =A0Perhaps it will be
>> better to see the hardware I'm talking about:
>> http://techreport.com/articles.x/16255
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-raid=
" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at =A0http://vger.kernel.org/majordomo-info.html
>>
>
>
>
> --
> Roberto Spadim
> Spadim Technology / SPAEmpresarial
>



--=20
Roberto Spadim
Spadim Technology / SPAEmpresarial
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" i=
n
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: support for external persistent cache

look this:
http://www.ramsan.com/products/4
http://www.ramsan.com/products/2


2011/1/19 Roberto Spadim :
> don=B4t forget that you can use ramdisks.... just read how to select =
the
> right memory, and the right position before initialize you ramdisk
>
> 2011/1/19 Roberto Spadim :
>> ok, your hardware have:
>> cpu, memory, disk controller, disks
>>
>> and you computer have:
>> cpu, memory, disk controler (your hardware)
>>
>> if your computer cache don=B4t sync to your disk controller you will
>> lose information....
>>
>> check that *memory, is the volatille memory and *disk controller is
>> the non volatille memory
>> if you tell me that you will never have a *memory, and you have alwa=
ys
>> a non volatille memory, no problem, you will never need a kernel
>> load... just a boot loader that read previous memory information and
>> start in that point... why don=B4t do this? non volatille memory is =
not
>> as fast as volatille memory
>> got the problem?
>>
>>
>> 2011/1/19 Cory Coager :
>>> On Wed, Jan 19, 2011 at 01:19:18PM -0200, Roberto Spadim wrote:
>>>> ok,
>>>> but if you don?t sync file system (remove from memory and put in d=
isk
>>>> controller)
>>>> you will lost information with or without a batery
>>>>
>>>> how to don?t lose information?
>>>> don?t power down you memory,cpu, disk controller (sata controler, =
raid
>>>> controller, or anyother) and disks (does it have a batery? a super
>>>> capacitor?)
>>>> if you power down, be sure that all memory was send to disk contro=
ller
>>>> and that disk controller have energy (batery or capacitor) to send
>>>> information to disks (they need batery or capacitor too)
>>>>
>>>> right?
>>>> so, a ups can power cpu, memory, disk controller and disks with on=
ly
>>>> one batery (not a batery for each device cpu,memory,disk,disk
>>>> controller)
>>>> the best world could be a non volatile memory (250mb/s flash 4kb
>>>> block) with the speed of volatile memory (10000mb/s ddr3 i don?t k=
now
>>>> the block size)
>>>
>>> It would have to work the same as a hardware RAID controller.
>>> Information is first written to the cache then synced to the
>>> disk. =A0If the data is in the cache but not on the disk, the
>>> machine loses power, next boot up the software raid would need a
>>> way to flush the data from the ram disk to the disk. =A0Of course
>>> this would require the battery be in working condition, as with
>>> any hardware.
>>>
>>> Hopefully I've explained that well enough. =A0Perhaps it will be
>>> better to see the hardware I'm talking about:
>>> http://techreport.com/articles.x/16255
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-rai=
d" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at =A0http://vger.kernel.org/majordomo-info.htm=
l
>>>
>>
>>
>>
>> --
>> Roberto Spadim
>> Spadim Technology / SPAEmpresarial
>>
>
>
>
> --
> Roberto Spadim
> Spadim Technology / SPAEmpresarial
>



--=20
Roberto Spadim
Spadim Technology / SPAEmpresarial
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" i=
n
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: support for external persistent cache

On Wed, Jan 19, 2011 at 02:16:08PM -0200, Roberto Spadim wrote:
> ok, your hardware have:
> cpu, memory, disk controller, disks
>
> and you computer have:
> cpu, memory, disk controler (your hardware)
>
> if your computer cache don?t sync to your disk controller you will
> lose information....
>
> check that *memory, is the volatille memory and *disk controller is
> the non volatille memory
> if you tell me that you will never have a *memory, and you have always
> a non volatille memory, no problem, you will never need a kernel
> load... just a boot loader that read previous memory information and
> start in that point... why don?t do this? non volatille memory is not
> as fast as volatille memory
> got the problem?

Sorry, we're still not on the same page. I would use both a ramdisk
and sata disk. The ramdisk would act as a persistent cache
(with the battery) for the sata disks. Enabling write through
would write to the cache first then sync to the sata disks.

Understand what I'm getting at now?
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: support for external persistent cache

yes, a jornaling but using ssd first and sata after
it=B4s not raid feature...
it=B4s per disk filesystem feature...
we could implement jornaling in raid too...
but=B4s more inteligent (easy) at application level (filesystem)
you could write first at network (if it=B4s faster than sata) and after
at sata (if it=B4s slower than network)

it=B4s not a raid feature... it=B4s a per device feature got it?
maybe a device (not raid..) for a cache division on devices
for example


/dev/sda (sata 1terabyte 100mb/s)
/dev/sdb (ssd 1gigabyte 1000mb/s)

/dev/cache_a (a mix of sata and ssd with sata size 1terabyte, and
mixed speed (memory, ssd, sata))

cache_a device should know that
early reads/write should be writen to sdb
time in time it should sync at sda

the same happens with memory (ram memory) but it=B4s volatille (diferen=
t
than ssd that=B4s not volatille)

/dev/sdb should be sync
/dev/sda should be async (since /dev/sdb make it safe to use async)


that=B4s you intention? i don=B4t know if linux have it, anyone know?


2011/1/19 Cory Coager :
> On Wed, Jan 19, 2011 at 02:16:08PM -0200, Roberto Spadim wrote:
>> ok, your hardware have:
>> cpu, memory, disk controller, disks
>>
>> and you computer have:
>> cpu, memory, disk controler (your hardware)
>>
>> if your computer cache don?t sync to your disk controller you will
>> lose information....
>>
>> check that *memory, is the volatille memory and *disk controller is
>> the non volatille memory
>> if you tell me that you will never have a *memory, and you have alwa=
ys
>> a non volatille memory, no problem, you will never need a kernel
>> load... just a boot loader that read previous memory information and
>> start in that point... why don?t do this? non volatille memory is no=
t
>> as fast as volatille memory
>> got the problem?
>
> Sorry, we're still not on the same page. =A0I would use both a ramdis=
k
> and sata disk. =A0The ramdisk would act as a persistent cache
> (with the battery) for the sata disks. =A0Enabling write through
> would write to the cache first then sync to the sata disks.
>
> Understand what I'm getting at now?
> --
> To unsubscribe from this list: send the line "unsubscribe linux-raid"=
in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at =A0http://vger.kernel.org/majordomo-info.html
>



--=20
Roberto Spadim
Spadim Technology / SPAEmpresarial
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" i=
n
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: support for external persistent cache

if /dev/sdb get full, /dev/sda must be sync before continue...
it=B4s a background thread
but it works like linux memory cache, but linux use ram (volatille)
you want a volatille (ssd)

it=B4s like this:
http://www.seagate.com/www/en-us/products/laptops/laptop-hdd

2011/1/19 Roberto Spadim :
> yes, a jornaling but using ssd first and sata after
> it=B4s not raid feature...
> it=B4s per disk filesystem feature...
> we could implement jornaling in raid too...
> but=B4s more inteligent (easy) at application level (filesystem)
> you could write first at network (if it=B4s faster than sata) and aft=
er
> at sata (if it=B4s slower than network)
>
> it=B4s not a raid feature... it=B4s a per device feature got it?
> maybe a device (not raid..) for a cache division on devices
> for example
>
>
> /dev/sda (sata 1terabyte 100mb/s)
> /dev/sdb (ssd 1gigabyte 1000mb/s)
>
> /dev/cache_a (a mix of sata and ssd with sata size 1terabyte, and
> mixed speed (memory, ssd, sata))
>
> cache_a device should know that
> early reads/write should be writen to sdb
> time in time it should sync at sda
>
> the same happens with memory (ram memory) but it=B4s volatille (difer=
ent
> than ssd that=B4s not volatille)
>
> /dev/sdb should be sync
> /dev/sda should be async (since /dev/sdb make it safe to use async)
>
>
> that=B4s you intention? i don=B4t know if linux have it, anyone know?
>
>
> 2011/1/19 Cory Coager :
>> On Wed, Jan 19, 2011 at 02:16:08PM -0200, Roberto Spadim wrote:
>>> ok, your hardware have:
>>> cpu, memory, disk controller, disks
>>>
>>> and you computer have:
>>> cpu, memory, disk controler (your hardware)
>>>
>>> if your computer cache don?t sync to your disk controller you will
>>> lose information....
>>>
>>> check that *memory, is the volatille memory and *disk controller is
>>> the non volatille memory
>>> if you tell me that you will never have a *memory, and you have alw=
ays
>>> a non volatille memory, no problem, you will never need a kernel
>>> load... just a boot loader that read previous memory information an=
d
>>> start in that point... why don?t do this? non volatille memory is n=
ot
>>> as fast as volatille memory
>>> got the problem?
>>
>> Sorry, we're still not on the same page. =A0I would use both a ramdi=
sk
>> and sata disk. =A0The ramdisk would act as a persistent cache
>> (with the battery) for the sata disks. =A0Enabling write through
>> would write to the cache first then sync to the sata disks.
>>
>> Understand what I'm getting at now?
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-raid=
" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at =A0http://vger.kernel.org/majordomo-info.html
>>
>
>
>
> --
> Roberto Spadim
> Spadim Technology / SPAEmpresarial
>



--=20
Roberto Spadim
Spadim Technology / SPAEmpresarial
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" i=
n
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: support for external persistent cache

On Wed, Jan 19, 2011 at 02:44:31PM -0200, Roberto Spadim wrote:
> yes, a jornaling but using ssd first and sata after
> it?s not raid feature...
> it?s per disk filesystem feature...
> we could implement jornaling in raid too...
> but?s more inteligent (easy) at application level (filesystem)
> you could write first at network (if it?s faster than sata) and after
> at sata (if it?s slower than network)
>
> it?s not a raid feature... it?s a per device feature got it?
> maybe a device (not raid..) for a cache division on devices
> for example
>
>
> /dev/sda (sata 1terabyte 100mb/s)
> /dev/sdb (ssd 1gigabyte 1000mb/s)
>
> /dev/cache_a (a mix of sata and ssd with sata size 1terabyte, and
> mixed speed (memory, ssd, sata))
>
> cache_a device should know that
> early reads/write should be writen to sdb
> time in time it should sync at sda
>
> the same happens with memory (ram memory) but it?s volatille (diferent
> than ssd that?s not volatille)
>
> /dev/sdb should be sync
> /dev/sda should be async (since /dev/sdb make it safe to use async)
>
>
> that?s you intention? i don?t know if linux have it, anyone know?
I would use a physical ramdisk over a ssd but thats besides the point.
They are still disk drives to the OS.

Yes, I guess it would be similar to journaling but done in RAID
itself. I don't believe it exists yet, thats why I'm asking if
we could add support for this?
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: support for external persistent cache

check:
Key Specifications

* 500GB, 320GB and 250GB hard drive capacity options (hard disk
like, maybe 100mb/s with 7200rpm - it=B4s you hd disk (/dev/sda in my
example) )
* 7200-RPM spindle speed
* 4GB SLC NAND solid state memory (SSD like, maybe 300mb/s -
it=B4s you ssd cache disk (/dev/sdb in my example) )
* 32MB of drive-level cache (is it ddr3? ddr3 is 10000mb/s, maybe
less, sata is 3gb/s - it=B4s the linux/computer ram memory)
* SATA 3Gb/s with Native Command Queuing (3000mb/s)

what this disk do?

operational system write to (hd) and read from (hd)

hd:
write/read in memory
if not in memory, read from ssd
if not in ssd, read from hd

write can be async
when loser energy, save memory to ssd, 32mb is fast to write, with
300mb/s ssd speed you can use a super capacitor and have 1 second of
life...
after write to ssd, write to hd





2011/1/19 Roberto Spadim :
> if /dev/sdb get full, /dev/sda must be sync before continue...
> it=B4s a background thread
> but it works like linux memory cache, but linux use ram (volatille)
> you want a volatille (ssd)
>
> it=B4s like this:
> http://www.seagate.com/www/en-us/products/laptops/laptop-hdd
>
> 2011/1/19 Roberto Spadim :
>> yes, a jornaling but using ssd first and sata after
>> it=B4s not raid feature...
>> it=B4s per disk filesystem feature...
>> we could implement jornaling in raid too...
>> but=B4s more inteligent (easy) at application level (filesystem)
>> you could write first at network (if it=B4s faster than sata) and af=
ter
>> at sata (if it=B4s slower than network)
>>
>> it=B4s not a raid feature... it=B4s a per device feature got it?
>> maybe a device (not raid..) for a cache division on devices
>> for example
>>
>>
>> /dev/sda (sata 1terabyte 100mb/s)
>> /dev/sdb (ssd 1gigabyte 1000mb/s)
>>
>> /dev/cache_a (a mix of sata and ssd with sata size 1terabyte, and
>> mixed speed (memory, ssd, sata))
>>
>> cache_a device should know that
>> early reads/write should be writen to sdb
>> time in time it should sync at sda
>>
>> the same happens with memory (ram memory) but it=B4s volatille (dife=
rent
>> than ssd that=B4s not volatille)
>>
>> /dev/sdb should be sync
>> /dev/sda should be async (since /dev/sdb make it safe to use async)
>>
>>
>> that=B4s you intention? i don=B4t know if linux have it, anyone know=
?
>>
>>
>> 2011/1/19 Cory Coager :
>>> On Wed, Jan 19, 2011 at 02:16:08PM -0200, Roberto Spadim wrote:
>>>> ok, your hardware have:
>>>> cpu, memory, disk controller, disks
>>>>
>>>> and you computer have:
>>>> cpu, memory, disk controler (your hardware)
>>>>
>>>> if your computer cache don?t sync to your disk controller you will
>>>> lose information....
>>>>
>>>> check that *memory, is the volatille memory and *disk controller i=
s
>>>> the non volatille memory
>>>> if you tell me that you will never have a *memory, and you have al=
ways
>>>> a non volatille memory, no problem, you will never need a kernel
>>>> load... just a boot loader that read previous memory information a=
nd
>>>> start in that point... why don?t do this? non volatille memory is =
not
>>>> as fast as volatille memory
>>>> got the problem?
>>>
>>> Sorry, we're still not on the same page. =A0I would use both a ramd=
isk
>>> and sata disk. =A0The ramdisk would act as a persistent cache
>>> (with the battery) for the sata disks. =A0Enabling write through
>>> would write to the cache first then sync to the sata disks.
>>>
>>> Understand what I'm getting at now?
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-rai=
d" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at =A0http://vger.kernel.org/majordomo-info.htm=
l
>>>
>>
>>
>>
>> --
>> Roberto Spadim
>> Spadim Technology / SPAEmpresarial
>>
>
>
>
> --
> Roberto Spadim
> Spadim Technology / SPAEmpresarial
>



--=20
Roberto Spadim
Spadim Technology / SPAEmpresarial
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" i=
n
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: support for external persistent cache

i think we could make it
but not a raid feature
a linux feature
for example

we could get ramdisk, nbd (network block device), ssd, hd, scsi, raid
and select what is first cache, and what is real value

after this device is created we could use it with raid...


but.... the problem persist
if we lost energy, we can=B4t confirm that ram memory is sync to disk,
just if we don=B4t use memory cache... in other words we will work with
the best cache disk speed)

since ram can get 32GB on big home computer
and ssd can get 1terabyte on big home computer
and hdd can get more than 1terabyte on big home computer

we just need time to sync 32GB from memory to ssd
what=B4s the ssd speed? 300mb/s? we need 106,6666666666667 seconds to
sync memory to ssd, can you buy a ups with 107 seconds of life with a
serial cable (usb maybe) that inform that we are without energy?





2011/1/19 Cory Coager :
> On Wed, Jan 19, 2011 at 02:44:31PM -0200, Roberto Spadim wrote:
>> yes, a jornaling but using ssd first and sata after
>> it?s not raid feature...
>> it?s per disk filesystem feature...
>> we could implement jornaling in raid too...
>> but?s more inteligent (easy) at application level (filesystem)
>> you could write first at network (if it?s faster than sata) and afte=
r
>> at sata (if it?s slower than network)
>>
>> it?s not a raid feature... it?s a per device feature got it?
>> maybe a device (not raid..) for a cache division on devices
>> for example
>>
>>
>> /dev/sda (sata 1terabyte 100mb/s)
>> /dev/sdb (ssd 1gigabyte 1000mb/s)
>>
>> /dev/cache_a (a mix of sata and ssd with sata size 1terabyte, and
>> mixed speed (memory, ssd, sata))
>>
>> cache_a device should know that
>> early reads/write should be writen to sdb
>> time in time it should sync at sda
>>
>> the same happens with memory (ram memory) but it?s volatille (difere=
nt
>> than ssd that?s not volatille)
>>
>> /dev/sdb should be sync
>> /dev/sda should be async (since /dev/sdb make it safe to use async)
>>
>>
>> that?s you intention? i don?t know if linux have it, anyone know?
> I would use a physical ramdisk over a ssd but thats besides the point=

> They are still disk drives to the OS.
>
> Yes, I guess it would be similar to journaling but done in RAID
> itself. =A0I don't believe it exists yet, thats why I'm asking if
> we could add support for this?
> --
> To unsubscribe from this list: send the line "unsubscribe linux-raid"=
in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at =A0http://vger.kernel.org/majordomo-info.html
>



--=20
Roberto Spadim
Spadim Technology / SPAEmpresarial
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" i=
n
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: support for external persistent cache

hummm....
thinking again.....

what=B4s the today raid1 problem?
it=B4s based on minimal disk size
for example...
/dev/sda 1gb
/dev/sdb 1tb
we can have a 1gb raid only

what you want is:
1tb raid0
with a automatic /dev/sda to /dev/sdb write


could we call this raid0-cache?
i think we could implement it in raid....

check this fuse (filesystem) implementation: http://www.furquim.org/chi=
ronfs/
it=B4s based on filesystem (ok it=B4s a raid1, not a cache like, but=B4=
s
limited to max filesystem size, not the minimal filesystem size... ok
it=B4s not secure to use it since small filesystem don=B4t have all
information, but=B4s nice)

anyone want to make raid0-cache implementation?


2011/1/19 Roberto Spadim :
> i think we could make it
> but not a raid feature
> a linux feature
> for example
>
> we could get ramdisk, nbd (network block device), ssd, hd, scsi, raid
> and select what is first cache, and what is real value
>
> after this device is created we could use it with raid...
>
>
> but.... the problem persist
> if we lost energy, we can=B4t confirm that ram memory is sync to disk=
,
> just if we don=B4t use memory cache... in other words we will work wi=
th
> the best cache disk speed)
>
> since ram can get 32GB on big home computer
> and ssd can get 1terabyte on big home computer
> and hdd can get more than 1terabyte on big home computer
>
> we just need time to sync 32GB from memory to ssd
> what=B4s the ssd speed? 300mb/s? we need 106,6666666666667 seconds to
> sync memory to ssd, can you buy a ups with 107 seconds of life with a
> serial cable (usb maybe) that inform that we are without energy?
>
>
>
>
>
> 2011/1/19 Cory Coager :
>> On Wed, Jan 19, 2011 at 02:44:31PM -0200, Roberto Spadim wrote:
>>> yes, a jornaling but using ssd first and sata after
>>> it?s not raid feature...
>>> it?s per disk filesystem feature...
>>> we could implement jornaling in raid too...
>>> but?s more inteligent (easy) at application level (filesystem)
>>> you could write first at network (if it?s faster than sata) and aft=
er
>>> at sata (if it?s slower than network)
>>>
>>> it?s not a raid feature... it?s a per device feature got it?
>>> maybe a device (not raid..) for a cache division on devices
>>> for example
>>>
>>>
>>> /dev/sda (sata 1terabyte 100mb/s)
>>> /dev/sdb (ssd 1gigabyte 1000mb/s)
>>>
>>> /dev/cache_a (a mix of sata and ssd with sata size 1terabyte, and
>>> mixed speed (memory, ssd, sata))
>>>
>>> cache_a device should know that
>>> early reads/write should be writen to sdb
>>> time in time it should sync at sda
>>>
>>> the same happens with memory (ram memory) but it?s volatille (difer=
ent
>>> than ssd that?s not volatille)
>>>
>>> /dev/sdb should be sync
>>> /dev/sda should be async (since /dev/sdb make it safe to use async)
>>>
>>>
>>> that?s you intention? i don?t know if linux have it, anyone know?
>> I would use a physical ramdisk over a ssd but thats besides the poin=
t.
>> They are still disk drives to the OS.
>>
>> Yes, I guess it would be similar to journaling but done in RAID
>> itself. =A0I don't believe it exists yet, thats why I'm asking if
>> we could add support for this?
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-raid=
" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at =A0http://vger.kernel.org/majordomo-info.html
>>
>
>
>
> --
> Roberto Spadim
> Spadim Technology / SPAEmpresarial
>



--=20
Roberto Spadim
Spadim Technology / SPAEmpresarial
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" i=
n
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: support for external persistent cache

On Wed, Jan 19, 2011 at 03:04:09PM -0200, Roberto Spadim wrote:
> check:
> Key Specifications
>
> * 500GB, 320GB and 250GB hard drive capacity options (hard disk
> like, maybe 100mb/s with 7200rpm - it?s you hd disk (/dev/sda in my
> example) )
> * 7200-RPM spindle speed
> * 4GB SLC NAND solid state memory (SSD like, maybe 300mb/s -
> it?s you ssd cache disk (/dev/sdb in my example) )
> * 32MB of drive-level cache (is it ddr3? ddr3 is 10000mb/s, maybe
> less, sata is 3gb/s - it?s the linux/computer ram memory)
> * SATA 3Gb/s with Native Command Queuing (3000mb/s)
>
> what this disk do?
>
> operational system write to (hd) and read from (hd)
>
> hd:
> write/read in memory
> if not in memory, read from ssd
> if not in ssd, read from hd
>
> write can be async
> when loser energy, save memory to ssd, 32mb is fast to write, with
> 300mb/s ssd speed you can use a super capacitor and have 1 second of
> life...
> after write to ssd, write to hd

Sounds about right. Can we make it happen?
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: support for external persistent cache

maybe it=B4s the intention of 'mcachefs'
http://sourceforge.net/apps/mediawiki/fuse/index.php?title=3 DFileSystem=
s



2011/1/19 Roberto Spadim :
> hummm....
> thinking again.....
>
> what=B4s the today raid1 problem?
> it=B4s based on minimal disk size
> for example...
> /dev/sda 1gb
> /dev/sdb 1tb
> we can have a 1gb raid only
>
> what you want is:
> 1tb raid0
> with a automatic /dev/sda to /dev/sdb write
>
>
> could we call this raid0-cache?
> i think we could implement it in raid....
>
> check this fuse (filesystem) implementation: http://www.furquim.org/c=
hironfs/
> it=B4s based on filesystem (ok it=B4s a raid1, not a cache like, but=B4=
s
> limited to max filesystem size, not the minimal filesystem size... ok
> it=B4s not secure to use it since small filesystem don=B4t have all
> information, but=B4s nice)
>
> anyone want to make raid0-cache implementation?
>
>
> 2011/1/19 Roberto Spadim :
>> i think we could make it
>> but not a raid feature
>> a linux feature
>> for example
>>
>> we could get ramdisk, nbd (network block device), ssd, hd, scsi, rai=
d
>> and select what is first cache, and what is real value
>>
>> after this device is created we could use it with raid...
>>
>>
>> but.... the problem persist
>> if we lost energy, we can=B4t confirm that ram memory is sync to dis=
k,
>> just if we don=B4t use memory cache... in other words we will work w=
ith
>> the best cache disk speed)
>>
>> since ram can get 32GB on big home computer
>> and ssd can get 1terabyte on big home computer
>> and hdd can get more than 1terabyte on big home computer
>>
>> we just need time to sync 32GB from memory to ssd
>> what=B4s the ssd speed? 300mb/s? we need 106,6666666666667 seconds t=
o
>> sync memory to ssd, can you buy a ups with 107 seconds of life with =
a
>> serial cable (usb maybe) that inform that we are without energy?
>>
>>
>>
>>
>>
>> 2011/1/19 Cory Coager :
>>> On Wed, Jan 19, 2011 at 02:44:31PM -0200, Roberto Spadim wrote:
>>>> yes, a jornaling but using ssd first and sata after
>>>> it?s not raid feature...
>>>> it?s per disk filesystem feature...
>>>> we could implement jornaling in raid too...
>>>> but?s more inteligent (easy) at application level (filesystem)
>>>> you could write first at network (if it?s faster than sata) and af=
ter
>>>> at sata (if it?s slower than network)
>>>>
>>>> it?s not a raid feature... it?s a per device feature got it?
>>>> maybe a device (not raid..) for a cache division on devices
>>>> for example
>>>>
>>>>
>>>> /dev/sda (sata 1terabyte 100mb/s)
>>>> /dev/sdb (ssd 1gigabyte 1000mb/s)
>>>>
>>>> /dev/cache_a (a mix of sata and ssd with sata size 1terabyte, and
>>>> mixed speed (memory, ssd, sata))
>>>>
>>>> cache_a device should know that
>>>> early reads/write should be writen to sdb
>>>> time in time it should sync at sda
>>>>
>>>> the same happens with memory (ram memory) but it?s volatille (dife=
rent
>>>> than ssd that?s not volatille)
>>>>
>>>> /dev/sdb should be sync
>>>> /dev/sda should be async (since /dev/sdb make it safe to use async=
)
>>>>
>>>>
>>>> that?s you intention? i don?t know if linux have it, anyone know?
>>> I would use a physical ramdisk over a ssd but thats besides the poi=
nt.
>>> They are still disk drives to the OS.
>>>
>>> Yes, I guess it would be similar to journaling but done in RAID
>>> itself. =A0I don't believe it exists yet, thats why I'm asking if
>>> we could add support for this?
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-rai=
d" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at =A0http://vger.kernel.org/majordomo-info.htm=
l
>>>
>>
>>
>>
>> --
>> Roberto Spadim
>> Spadim Technology / SPAEmpresarial
>>
>
>
>
> --
> Roberto Spadim
> Spadim Technology / SPAEmpresarial
>



--=20
Roberto Spadim
Spadim Technology / SPAEmpresarial
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" i=
n
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: support for external persistent cache

i=B4m not a good person to implement raid at kernel level, maybe at fus=
e level

neil have more time in this forum than me
neilb@suse.de

i=B4m new here =3D) hihi

i will make a new post this is very big...


2011/1/19 Cory Coager :
> On Wed, Jan 19, 2011 at 03:04:09PM -0200, Roberto Spadim wrote:
>> check:
>> Key Specifications
>>
>> =A0 =A0 * 500GB, 320GB and 250GB hard drive capacity options =A0 (ha=
rd disk
>> like, maybe 100mb/s with 7200rpm =A0 - it?s you hd disk (/dev/sda in=
my
>> example) )
>> =A0 =A0 * 7200-RPM spindle speed
>> =A0 =A0 * 4GB SLC NAND solid state memory =A0 (SSD like, maybe 300mb=
/s =A0 -
>> it?s you ssd cache disk (/dev/sdb in my example) )
>> =A0 =A0 * 32MB of drive-level cache =A0(is it ddr3? ddr3 is 10000mb/=
s, maybe
>> less, sata is 3gb/s =A0 =A0- it?s the linux/computer ram memory)
>> =A0 =A0 * SATA 3Gb/s with Native Command Queuing (3000mb/s)
>>
>> what this disk do?
>>
>> operational system write to (hd) and read from (hd)
>>
>> hd:
>> write/read in memory
>> if not in memory, read from ssd
>> if not in ssd, read from hd
>>
>> write can be async
>> when loser energy, save memory to ssd, 32mb is fast to write, with
>> 300mb/s ssd speed you can use a super capacitor and have 1 second of
>> life...
>> after write to ssd, write to hd
>
> Sounds about right. =A0Can we make it happen?
> --
> To unsubscribe from this list: send the line "unsubscribe linux-raid"=
in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at =A0http://vger.kernel.org/majordomo-info.html
>



--=20
Roberto Spadim
Spadim Technology / SPAEmpresarial
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" i=
n
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: support for external persistent cache

On Wed, Jan 19, 2011 at 03:15:40PM -0200, Roberto Spadim wrote:
> hummm....
> thinking again.....
>
> what?s the today raid1 problem?
> it?s based on minimal disk size
> for example...
> /dev/sda 1gb
> /dev/sdb 1tb
> we can have a 1gb raid only
>
> what you want is:
> 1tb raid0
> with a automatic /dev/sda to /dev/sdb write
>
>
> could we call this raid0-cache?
> i think we could implement it in raid....
>
> check this fuse (filesystem) implementation: http://www.furquim.org/chironfs/
> it?s based on filesystem (ok it?s a raid1, not a cache like, but?s
> limited to max filesystem size, not the minimal filesystem size... ok
> it?s not secure to use it since small filesystem don?t have all
> information, but?s nice)
>
> anyone want to make raid0-cache implementation?

I have two comments on this.

I don't think the cache device should be the same size as your
disk storage. It should be a small cache size similar to
hardware RAID.

Also, we'd need a way to flush the data from the cache device
on bootup.
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: support for external persistent cache

please check my email =3D)
let=B4s end this email?

2011/1/19 Cory Coager :
> On Wed, Jan 19, 2011 at 03:15:40PM -0200, Roberto Spadim wrote:
>> hummm....
>> thinking again.....
>>
>> what?s the today raid1 problem?
>> it?s based on minimal disk size
>> for example...
>> /dev/sda 1gb
>> /dev/sdb 1tb
>> we can have a 1gb raid only
>>
>> what you want is:
>> 1tb raid0
>> with a automatic /dev/sda to /dev/sdb write
>>
>>
>> could we call this raid0-cache?
>> i think we could implement it in raid....
>>
>> check this fuse (filesystem) implementation: http://www.furquim.org/=
chironfs/
>> it?s based on filesystem (ok it?s a raid1, not a cache like, but?s
>> limited to max filesystem size, not the minimal filesystem size... o=
k
>> it?s not secure to use it since small filesystem don?t have all
>> information, but?s nice)
>>
>> anyone want to make raid0-cache implementation?
>
> I have two comments on this.
>
> I don't think the cache device should be the same size as your
> disk storage. =A0It should be a small cache size similar to
> hardware RAID.
>
> Also, we'd need a way to flush the data from the cache device
> on bootup.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-raid"=
in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at =A0http://vger.kernel.org/majordomo-info.html
>



--=20
Roberto Spadim
Spadim Technology / SPAEmpresarial
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" i=
n
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html