public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Shaun Savage <savages@savages.net>
To: Phillip Susi <psusi@cfl.rr.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: CBD Compressed Block Device, New embedded block device
Date: Mon, 23 Jan 2006 03:34:01 -0800	[thread overview]
Message-ID: <43D4BF29.5090208@savages.net> (raw)
In-Reply-To: <43D3A9D1.2060800@cfl.rr.com>

CBD is designed for embedded systems.  The compression starts off the 
similar to cloop, The filesystem partitions are created in files,  These 
partition files are broken into 32K blocks( the window size of gzip).   
Now there is a compressed file  and a array of start  locations. This is 
placed into a  CBD  partition package  (CBDpp), by adding a header. This 
header includes version, hash, signature,.... 

The flash device is divided 64K blocks,  you can think of these as 
sectors.  There is a user program that writes new CBDpp  to these 
blocks.  The CBDpp are run length encoded. There is a table of which 
blocks are used by the CBDpp in the header of the CBDpp.  On startup the 
driver searches the blocks for the MAGIC header.  When it finds one it 
read the header and maps which blocks holds the CBDpp.  The driver then 
does not search thoses blocks.  Empty block devices are slow to boot 
while full ones are fast.

There is a patch for GRUB that know about the CBD headers.  It search 
for the latest and greatest version of the CBDpp.  The allows for in the 
field system update.

partition 0 is the bootloader and kernel, and othe global system stuff.
partition 1 is the root file system

The one unique feature is any filesystem can be on top AND it support 
writes!!   Now the write never make it to the physical device, but the 
write data is locked in buffer cache.  Yes I know this can be a memory 
leak, but in an embedded device the writes are configuration and patches.

I received lots of email on how to improve the code, Which I am doing.  
I will answer your emails in how fast I can make those changes.

shaun


Phillip Susi wrote:

> How is this different from cloop or dm-crypt?
>
> Shaun Savage wrote:
>
>> HI
>>
>> Here is a patch for 2.6.14.5 of CBD
>> CBD is a compressed block device that is designed to shrink the file 
>> system size to 1/3 the original size.  CBD is a block device on a 
>> file system so, it also allows for in-field upgrade of file system.  
>> If necessary is also allows for secure booting, with a GRUB patch.
>>
>> Reply to email please.
>>
>> Shaun Savage
>
>


      parent reply	other threads:[~2006-01-22 22:27 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-01-22  8:46 CBD Compressed Block Device, New embedded block device Shaun Savage
2006-01-21 19:53 ` Arjan van de Ven
2006-01-21 21:09 ` Randy.Dunlap
2006-01-21 22:05 ` Alexey Dobriyan
2006-01-21 22:22 ` Matt Mackall
2006-01-22  8:26 ` Pavel Machek
2006-01-23  2:26   ` Shaun Savage
2006-01-22 15:50 ` Phillip Susi
2006-01-22 18:26   ` Jan Engelhardt
2006-01-23 11:34   ` Shaun Savage [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=43D4BF29.5090208@savages.net \
    --to=savages@savages.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=psusi@cfl.rr.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox