[PATCH 2/2] Handle group offsets in UFS1

[PATCH 2/2] Handle group offsets in UFS1

[Vladimir 'phcoder' Serbinenko]

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

-- 
Regards
Vladimir 'phcoder' Serbinenko

Personal git repository: http://repo.or.cz/w/grub2/phcoder.git

[-- Attachment #2: ufsfix --]
[-- Type: application/octet-stream, Size: 1215 bytes --]

diff --git a/ChangeLog b/ChangeLog
index 8e13775..be2eca0 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,12 @@
 2009-08-13  Vladimir Serbinenko  <phcoder@gmail.com>
 
+	Handle group offset on UFS1.
+
+	* fs/ufs.c (grub_ufs_sblock): New field 'cylg_mask'.
+	(grub_ufs_read_inode) [!MODE_UFS2]: handle cylg_offset and cylg_mask.
+	
+2009-08-13  Vladimir Serbinenko  <phcoder@gmail.com>
+
 	Split ufs.mod into ufs1.mod and ufs2.mod.
 
 	* conf/common.rmk (grub_probe_SOURCES): Add fs/ufs2.c.
diff --git a/fs/ufs.c b/fs/ufs.c
index 7f254af..13727f8 100644
--- a/fs/ufs.c
+++ b/fs/ufs.c
@@ -88,7 +88,7 @@ struct grub_ufs_sblock
 
   /* The start of the cylinder group.  */
   grub_uint32_t cylg_offset;
-  grub_uint8_t unused3[4];
+  grub_uint32_t cylg_mask;
 
   grub_uint32_t mtime;
   grub_uint8_t unused4[12];
@@ -360,6 +360,11 @@ grub_ufs_read_inode (struct grub_ufs_data *data, int ino, char *inode)
   /* The first block of the group.  */
   int grpblk = group * (grub_le_to_cpu32 (sblock->frags_per_group));
 
+#ifndef MODE_UFS2
+  grpblk += grub_le_to_cpu32 (sblock->cylg_offset)
+    * (group & (~grub_le_to_cpu32 (sblock->cylg_mask)));
+#endif
+
   if (!inode)
     {
       inode = (char *) &data->inode;

Re: [PATCH 2/2] Handle group offsets in UFS1

[Robert Millan]

On Thu, Aug 13, 2009 at 06:04:35PM +0200, Vladimir 'phcoder' Serbinenko wrote:

This looks a bit odd (a mask applied to an integer?), but if it's really
this way, please go ahead with it.

Btw, your mailer marked this attachment as application/octet-stream (I can't
context-reply :-( )

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

Re: [PATCH 2/2] Handle group offsets in UFS1

[Seth Goldberg]

Hi,

   Yes, that's really the way it is :).

  --S

Quoting Robert Millan, who wrote the following on Thu, 13 Aug 2009:

> On Thu, Aug 13, 2009 at 06:04:35PM +0200, Vladimir 'phcoder' Serbinenko wrote:
>
> This looks a bit odd (a mask applied to an integer?), but if it's really
> this way, please go ahead with it.
>
> Btw, your mailer marked this attachment as application/octet-stream (I can't
> context-reply :-( )
>
> -- 
> Robert Millan
>
>  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
>  how) you may access your data; but nobody's threatening your freedom: we
>  still allow you to remove your data and not access it at all."
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>

Re: [PATCH 2/2] Handle group offsets in UFS1

[Vladimir 'phcoder' Serbinenko]

On Thu, Aug 13, 2009 at 10:05 PM, Robert Millan<rmh@aybabtu.com> wrote:
> On Thu, Aug 13, 2009 at 06:04:35PM +0200, Vladimir 'phcoder' Serbinenko wrote:
>
> This looks a bit odd (a mask applied to an integer?), but if it's really
> this way, please go ahead with it.
>
It's the so-called skewness.
Let's say you place inodes on addresses (C/H/S)
(0/0/1) and (1/0/1) you first read the metadata at (0/0/1) then you
try to fetch the metadata from (0/1/1). Responding to your request
harddrive moves the head to cylinder number 1 but it takes some time.
Meanwhile the plates have spinned (they are spinning constantly) and
perhaps head is above sector (1/0/10) and you need to wait for
complete rotation to fetch your sector.
If you write inodes at (0/0/1) and (1/0/15) you will need to wait only
for 4 sectors. This is called skewness and was an optimisation
technique in the past. But now OS doesn't know about physical geometry
and so can't do such kind of optimisation. I suppose it's why it's not
used anymore for UFS2. I don't know if FreeBSD variant of UFS1 still
uses this feature.
> Btw, your mailer marked this attachment as application/octet-stream (I can't
> context-reply :-( )
>
I forgot the extension. Sorry.
> --
> Robert Millan
>
>  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
>  how) you may access your data; but nobody's threatening your freedom: we
>  still allow you to remove your data and not access it at all."
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>



-- 
Regards
Vladimir 'phcoder' Serbinenko

Personal git repository: http://repo.or.cz/w/grub2/phcoder.git

Re: [PATCH 2/2] Handle group offsets in UFS1

[Robert Millan]

On Thu, Aug 13, 2009 at 10:25:15PM +0200, Vladimir 'phcoder' Serbinenko wrote:
> On Thu, Aug 13, 2009 at 10:05 PM, Robert Millan<rmh@aybabtu.com> wrote:
> > On Thu, Aug 13, 2009 at 06:04:35PM +0200, Vladimir 'phcoder' Serbinenko wrote:
> >
> > This looks a bit odd (a mask applied to an integer?), but if it's really
> > this way, please go ahead with it.
> >
> It's the so-called skewness.
> Let's say you place inodes on addresses (C/H/S)
> (0/0/1) and (1/0/1) you first read the metadata at (0/0/1) then you
> try to fetch the metadata from (0/1/1). Responding to your request
> harddrive moves the head to cylinder number 1 but it takes some time.
> Meanwhile the plates have spinned (they are spinning constantly) and
> perhaps head is above sector (1/0/10) and you need to wait for
> complete rotation to fetch your sector.
> If you write inodes at (0/0/1) and (1/0/15) you will need to wait only
> for 4 sectors. This is called skewness and was an optimisation
> technique in the past. But now OS doesn't know about physical geometry
> and so can't do such kind of optimisation. I suppose it's why it's not
> used anymore for UFS2. I don't know if FreeBSD variant of UFS1 still
> uses this feature.

I see :-)

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."