storeio problem [PATCH]

[Marco Gerards]

Hi,

There is a problem with storeio.  Ognyan reported this on savannah
already:

https://savannah.gnu.org/bugs/?func=detailitem&item_id=10440

The problem is that the size of /dev is huge (which is reported by `ls
-l' as total).  This is caused by /dev/zero:

9007199254740992 crw-rw-rw-  1 root root 0, 0 Jul 13 07:20 /dev/zero

The reason why /dev/zero is this big, is because the zero store is
used.  It's default size is set like this (libstore/zero.c):

      store_offset_t max_offs = ~((store_offset_t)1
                                  << (CHAR_BIT * sizeof (store_offset_t) - 1));
      return store_zero_create (max_offs, flags, store);

One fix is just making storeio ignore the size of the store.  In that
case /dev on GNU/Hurd would look just like that of GNU/Linux.  The
disadvantage of this approach might be that we break a lot of stuff
like this.  I am not sure how many programs request the size of a disk
by using st_blocks.  I have written a patch that does exactly this.

Another way to fix this would be is checking if the size of a store is
max_offs and in that case report it as 0.

In case of the last solution the devices (the disks and partitions)
will be uses to calculate the total size of /dev.  This seems a bit
awkward to me.

But in the case the current behavior is ok, we can close the bug on
savannah.

Thanks,
Marco




2005-01-07  Marco Gerards  <metgerards@student.han.nl>

        * storeio.c (trivfs_modify_stat): Set st_blocks to 0.



Index: storeio.c
===================================================================
RCS file: /cvsroot/hurd/hurd/storeio/storeio.c,v
retrieving revision 1.24
diff -u -p -r1.24 storeio.c
--- storeio.c   22 Jun 2002 21:13:26 -0000      1.24
+++ storeio.c   6 Jan 2005 23:16:09 -0000
@@ -299,7 +299,7 @@ trivfs_modify_stat (struct trivfs_protid
        st->st_blksize = store->block_size;
 
       st->st_size = size;
-      st->st_blocks = size / 512;
+      st->st_blocks = 0;
 
       st->st_mode |= ((dev->inhibit_cache || store->block_size == 1)
                      ? S_IFCHR : S_IFBLK);