date:20070722

ANN: Labeled NFS mailing list

2007-07-22 Thread James Morris

The folk at linux-nfs.org have kindly setup a mailing list for the Labeled 
NFS development effort.

The purpose of the list is for initial analysis and design of a mandatory 
access control (MAC) extension to NFSv4, in support of SELinux and other 
MAC schemes across different platforms.

For mailing list subscription information, please see: 
http://linux-nfs.org/cgi-bin/mailman/listinfo/labeled-nfs

Prior discussion of this project (which started out as SELinux-specific) 
may be found at: http://thread.gmane.org/gmane.linux.nfsv4/5341


-- 
James Morris
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-fsdevel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFH] Partition table recovery

2007-07-22 Thread Theodore Tso

On Sun, Jul 22, 2007 at 07:10:31AM +0300, Al Boldi wrote:
 Sounds great, but it may be advisable to hook this into the partition 
 modification routines instead of mkfs/fsck.  Which would mean that the 
 partition manager could ask the kernel to instruct its fs subsystem to 
 update the backup partition table for each known fs-type that supports such 
 a feature.

Well, let's think about this a bit.  What are the requirements?

1) The partition manager should be able explicitly request that a new
backup of the partition tables be stashed in each filesystem that has
room for such a backup.  That way, when the user affirmatively makes a
partition table change, it can get backed up in all of the right
places automatically.

2) The fsck program should *only* stash a backup of the partition
table if there currently isn't one in the filesystem.  It may be that
the partition table has been corrupted, and so merely doing an fsck
should not transfer a current copy of the partition table to the
filesystem-secpfic backup area.  It could be that the partition table
was only partially recovered, and we don't want to overwrite the
previously existing backups except on an explicit request from the
system administrator.

3) The mkfs program should automatically create a backup of the
current partition table layout.  That way we get a backup in the newly
created filesystem as soon as it is created.

4) The exact location of the backup may vary from filesystem to
filesystem.  For ext2/3/4, bytes 512-1023 are always unused, and don't
interfere with the boot sector at bytes 0-511, so that's the obvious
location.  Other filesystems may have that location in use, and some
other location might be a better place to store it.  Ideally it will
be a well-known location, that isn't dependent on finding an inode
table, or some such, but that may not be possible for all filesystems.

OK, so how about this as a solution that meets the above requirements?

/sbin/partbackup device [fspart]

Will scan device (i.e., /dev/hda, /dev/sdb, etc.) and create
a 512 byte partition backup, using the format I've previously
described.  If fspart is specified on the command line, it
will use the blkid library to determine the filesystem type of
fspart, and then attempt to execute
/dev/partbackupfs.fstype to write the partition backup to
fspart.  If fspart is '-', then it will write the 512 byte
partition table to stdout.  If fspart is not specified on
the command line, /sbin/partbackup will iterate over all
partitions in device, use the blkid library to attempt to
determine the correct filesystem type, and then execute 
/sbin/partbackupfs.fstype if such a backup program exists.

/sbin/partbackupfs.fstype fspart

... is a filesystem specific program for filesystem type
fstype.  It will assure that fspart (i.e., /dev/hda1,
/dev/sdb3) is of an appropriate filesystem type, and then read
512 bytes from stdin and write it out to fspart to an
appropriate place for that filesystem.

Partition managers will be encouraged to check to see if
/sbin/partbackup exists, and if so, after the partition table is
written, will check to see if /sbin/partbackup exists, and if so, to
call it with just one argument (i.e., /sbin/partbackup /dev/hdb).
They SHOULD provide an option for the user to suppress the backup from
happening, but the backup should be the default behavior.

An /etc/mkfs.fstype program is encouraged to run /sbin/partbackup
with two arguments (i.e., /sbin/partbackup /dev/hdb /dev/hdb3) when
creating a filesystem.

An /etc/fsck.fstype program is encouraged to check to see if a
partition backup exists (assuming the filesystem supports it), and if
not, call /sbin/partbackup with two arguments.

A filesystem utility package for a particular filesystem type is
encouraged to make the above changes to its mkfs and fsck programs, as
well as provide an /sbin/partbackupfs.fstype program.

I would do this all in userspace, though.  Is there any reason to get
the kernel involved?  I don't think so.

- Ted
-
To unsubscribe from this list: send the line unsubscribe linux-fsdevel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFH] Partition table recovery

2007-07-22 Thread Al Boldi

Theodore Tso wrote:
 On Sun, Jul 22, 2007 at 07:10:31AM +0300, Al Boldi wrote:
  Sounds great, but it may be advisable to hook this into the partition
  modification routines instead of mkfs/fsck.  Which would mean that the
  partition manager could ask the kernel to instruct its fs subsystem to
  update the backup partition table for each known fs-type that supports
  such a feature.

 Well, let's think about this a bit.  What are the requirements?

 1) The partition manager should be able explicitly request that a new
 backup of the partition tables be stashed in each filesystem that has
 room for such a backup.  That way, when the user affirmatively makes a
 partition table change, it can get backed up in all of the right
 places automatically.

 2) The fsck program should *only* stash a backup of the partition
 table if there currently isn't one in the filesystem.  It may be that
 the partition table has been corrupted, and so merely doing an fsck
 should not transfer a current copy of the partition table to the
 filesystem-secpfic backup area.  It could be that the partition table
 was only partially recovered, and we don't want to overwrite the
 previously existing backups except on an explicit request from the
 system administrator.

 3) The mkfs program should automatically create a backup of the
 current partition table layout.  That way we get a backup in the newly
 created filesystem as soon as it is created.

 4) The exact location of the backup may vary from filesystem to
 filesystem.  For ext2/3/4, bytes 512-1023 are always unused, and don't
 interfere with the boot sector at bytes 0-511, so that's the obvious
 location.  Other filesystems may have that location in use, and some
 other location might be a better place to store it.  Ideally it will
 be a well-known location, that isn't dependent on finding an inode
 table, or some such, but that may not be possible for all filesystems.

 OK, so how about this as a solution that meets the above requirements?

 /sbin/partbackup device [fspart]

   Will scan device (i.e., /dev/hda, /dev/sdb, etc.) and create
   a 512 byte partition backup, using the format I've previously
   described.  If fspart is specified on the command line, it
   will use the blkid library to determine the filesystem type of
   fspart, and then attempt to execute
   /dev/partbackupfs.fstype to write the partition backup to
   fspart.  If fspart is '-', then it will write the 512 byte
   partition table to stdout.  If fspart is not specified on
   the command line, /sbin/partbackup will iterate over all
   partitions in device, use the blkid library to attempt to
   determine the correct filesystem type, and then execute
   /sbin/partbackupfs.fstype if such a backup program exists.

 /sbin/partbackupfs.fstype fspart

   ... is a filesystem specific program for filesystem type
   fstype.  It will assure that fspart (i.e., /dev/hda1,
   /dev/sdb3) is of an appropriate filesystem type, and then read
   512 bytes from stdin and write it out to fspart to an
   appropriate place for that filesystem.

 Partition managers will be encouraged to check to see if
 /sbin/partbackup exists, and if so, after the partition table is
 written, will check to see if /sbin/partbackup exists, and if so, to
 call it with just one argument (i.e., /sbin/partbackup /dev/hdb).
 They SHOULD provide an option for the user to suppress the backup from
 happening, but the backup should be the default behavior.

 An /etc/mkfs.fstype program is encouraged to run /sbin/partbackup
 with two arguments (i.e., /sbin/partbackup /dev/hdb /dev/hdb3) when
 creating a filesystem.

 An /etc/fsck.fstype program is encouraged to check to see if a
 partition backup exists (assuming the filesystem supports it), and if
 not, call /sbin/partbackup with two arguments.

 A filesystem utility package for a particular filesystem type is
 encouraged to make the above changes to its mkfs and fsck programs, as
 well as provide an /sbin/partbackupfs.fstype program.

Great!

 I would do this all in userspace, though.  Is there any reason to get
 the kernel involved?  I don't think so.

Yes, doing things in userspace, when possible, is much better.  But, a change 
in the partition table has to be relayed to the kernel, and when that change 
happens to be on a mounted disk, then the partition manager complains of not 
being able to update the kernel's view.  So how can this be addressed?


Thanks!

--
Al

-
To unsubscribe from this list: send the line unsubscribe linux-fsdevel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFH] Partition table recovery

2007-07-22 Thread Indan Zupancic

On Sun, July 22, 2007 18:28, Theodore Tso wrote:
 On Sun, Jul 22, 2007 at 07:10:31AM +0300, Al Boldi wrote:
 Sounds great, but it may be advisable to hook this into the partition
 modification routines instead of mkfs/fsck.  Which would mean that the
 partition manager could ask the kernel to instruct its fs subsystem to
 update the backup partition table for each known fs-type that supports such
 a feature.

 Well, let's think about this a bit.  What are the requirements?

 1) The partition manager should be able explicitly request that a new
 backup of the partition tables be stashed in each filesystem that has
 room for such a backup.  That way, when the user affirmatively makes a
 partition table change, it can get backed up in all of the right
 places automatically.

 2) The fsck program should *only* stash a backup of the partition
 table if there currently isn't one in the filesystem.  It may be that
 the partition table has been corrupted, and so merely doing an fsck
 should not transfer a current copy of the partition table to the
 filesystem-secpfic backup area.  It could be that the partition table
 was only partially recovered, and we don't want to overwrite the
 previously existing backups except on an explicit request from the
 system administrator.

 3) The mkfs program should automatically create a backup of the
 current partition table layout.  That way we get a backup in the newly
 created filesystem as soon as it is created.

 4) The exact location of the backup may vary from filesystem to
 filesystem.  For ext2/3/4, bytes 512-1023 are always unused, and don't
 interfere with the boot sector at bytes 0-511, so that's the obvious
 location.  Other filesystems may have that location in use, and some
 other location might be a better place to store it.  Ideally it will
 be a well-known location, that isn't dependent on finding an inode
 table, or some such, but that may not be possible for all filesystems.

To be on the safe side, maybe also add a checksum, timestamp and
something identifying the disk the filesystem was created on.

Regards,

Indan


-
To unsubscribe from this list: send the line unsubscribe linux-fsdevel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [EXT4 set 7][PATCH 1/1]Remove 32000 subdirs limit.

2007-07-22 Thread Ingo Oeser

On Tuesday 17 July 2007, Kalpak Shah wrote:
 Index: linux-2.6.22/include/linux/ext4_fs.h
 ===
 --- linux-2.6.22.orig/include/linux/ext4_fs.h
 +++ linux-2.6.22/include/linux/ext4_fs.h
 @@ -797,12 +797,18 @@ struct ext4_dir_entry_2 {
#define is_dx(dir) (EXT4_HAS_COMPAT_FEATURE(dir-i_sb, \
   EXT4_FEATURE_COMPAT_DIR_INDEX) 
  \
   (EXT4_I(dir)-i_flags  EXT4_INDEX_FL))
 -#define EXT4_DIR_LINK_MAX(dir) (!is_dx(dir)  (dir)-i_nlink = 
 EXT4_LINK_MAX)
 -#define EXT4_DIR_LINK_EMPTY(dir) ((dir)-i_nlink == 2 || (dir)-i_nlink == 1)
 +static inline int ext4_dir_link_max(struct inode *dir)
 +{
 +   return (!is_dx(dir)  (dir)-i_nlink = EXT4_LINK_MAX);
 +}
 +static inline int ext4_dir_link_empty(struct inode *dir)
 +{
 +   return ((dir)-i_nlink == 2 || (dir)-i_nlink == 1);
 +}

even better:

static inline bool ext4_is_dx(const struct inode *dir)
{
#ifdef FOOBAR
return EXT4_HAS_COMPAT_FEATURE(dir-i_sb,   
EXT4_FEATURE_COMPAT_DIR_INDEX) 
(EXT4_I(dir)-i_flags  EXT4_INDEX_FL));
#else
return false;
#endif
}

static inline bool ext4_dir_link_max(const struct inode *dir)
{
return !ext4_is_dx(dir)  (dir-i_nlink = EXT4_LINK_MAX);
}

static inline bool ext4_dir_link_empty(const struct inode *dir)
{
#ifdef FOOBAR
return dir-i_nlink == 2 || dir-i_nlink == 1;
#else
return dir-i_nlink == 2;
#endif
}


FOOBAR is the define, which enables ext4_is_dx(). 
That is not in the patch, so left as an exercise to the reader :-)

Best Regards

Ingo Oeser
-
To unsubscribe from this list: send the line unsubscribe linux-fsdevel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

ANN: Labeled NFS mailing list

Re: [RFH] Partition table recovery

Re: [RFH] Partition table recovery

Re: [RFH] Partition table recovery

Re: [EXT4 set 7][PATCH 1/1]Remove 32000 subdirs limit.

5 matches

Site Navigation

Mail list logo

Footer information