Plugin modifications to disk format.

Plugin modifications to disk format.

[Peter van Hardenberg]

More codework today, so more questions.

inodes:
----------
We would like to add a new field to every inode on disc. This could monopolize 
the "plugin_data" union on the struct. Is there a better way? How can this be 
achieved without breaking format compatibility?

Storage:
-----------
How tightly can these attribute directories be packed? Dominic Giampaulo 
rejected a similar design to ours for efficiency purposes in the BeFS, but he 
was not lucky enough to have the advantages of the Reiser storage layer 
underneath. So... since we have those advantages, how tight can we pack the 
following:

Small file with an attribute directory:
inode
	->data
	->attributedir_inode
		->attributedir_ dir_file
			->attribute_inode
				->attribute_data 

-- 
Peter van Hardenberg (pvh@pvh.ca)
Victoria, BC, Canada

Re: Plugin modifications to disk format.

[Vladimir V. Saveliev]

Hello

Peter van Hardenberg wrote:
> More codework today, so more questions.
> 
> inodes:
> ----------
> We would like to add a new field to every inode on disc. 

inode on disk is called stat data in reiser4.
To add a new field to stat data one would have to write sd extension plugin.
reiser4/plugin/item/static_stat.[ch] should help you to get started.

reiser4progs are to be updated to understand new extension plugin.

> This could monopolize 
> the "plugin_data" union on the struct. 

Which struct do you mean?

> Is there a better way? How can this be 
> achieved without breaking format compatibility?
> 
> Storage:
> -----------
> How tightly can these attribute directories be packed? Dominic Giampaulo 
> rejected a similar design to ours for efficiency purposes in the BeFS, but he 
> was not lucky enough to have the advantages of the Reiser storage layer 
> underneath. So... since we have those advantages, how tight can we pack the 
> following:
> 
> Small file with an attribute directory:
> inode
> 	->data
> 	->attributedir_inode
> 		->attributedir_ dir_file
> 			->attribute_inode
> 				->attribute_data 
> 

Re: Plugin modifications to disk format.

[Hans Reiser]

Peter van Hardenberg wrote:

>More codework today, so more questions.
>
>inodes:
>----------
>We would like to add a new field to every inode on disc. This could monopolize 
>the "plugin_data" union on the struct. Is there a better way? How can this be 
>achieved without breaking format compatibility?
>
>Storage:
>-----------
>How tightly can these attribute directories be packed? Dominic Giampaulo 
>rejected a similar design to ours for efficiency purposes in the BeFS, but he 
>was not lucky enough to have the advantages of the Reiser storage layer 
>underneath. So... since we have those advantages, how tight can we pack the 
>following:
>
>Small file with an attribute directory:
>inode
>	->data
>	->attributedir_inode
>		->attributedir_ dir_file
>			->attribute_inode
>				->attribute_data 
>
>  
>
define how an attribute differs from a file, usefully that is.....

Hans