filesystem differentiation

filesystem differentiation

[Peter Teoh]

given different harddisk partition, does anyone knows how to
differentiate one partition from another?

at the kernel source level, which is the constant/variable for this?

Is it EXT3_XATTR_MAGIC?   (but EXT2_XATTR_MAGIC have the same value as
ext3, so betw the two they are not distinguisable?)
(or REISERFS_XATTR_MAGIC etc)   So I supposed if I were to create my
new filesystem, then just create a new /random value from this?

-- 
Regards,
Peter Teoh

Re: filesystem differentiation

[Andreas Dilger]

On Mar 15, 2008  00:17 +0800, Peter Teoh wrote:
> given different harddisk partition, does anyone knows how to
> differentiate one partition from another?
> 
> at the kernel source level, which is the constant/variable for this?
> 
> Is it EXT3_XATTR_MAGIC?   (but EXT2_XATTR_MAGIC have the same value as
> ext3, so betw the two they are not distinguisable?)
> (or REISERFS_XATTR_MAGIC etc)

Read the file (1) and blkid (8) man pages.  These tools understand a
lot of different magic numbers for filesystems:

# file -s /dev/sda1
/dev/sda1: Linux rev 1.0 ext3 filesystem data (needs journal recovery) (large
files)

# blkid /dev/sda1
/dev/sda1: LABEL="/boot" UUID="1fe1d719-1a8c-45a0-969a-cba8b101cc57"
SEC_TYPE="ext2" TYPE="ext3"

> So I supposed if I were to create my
> new filesystem, then just create a new /random value from this?

Pretty much, yes.  You should also add a LABEL and UUID field so that one
instance of the filesystem can be distinguished from another.

A better goal (IMHO) than creating your own new filesystem is to help out
some existing filesystem like ext4 or btrfs.

Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.

"Write once only but read many" filesystem

[Peter Teoh]

For reasons of auditability/accountability, I would like a filesystem 
such that I can write to it only ONCE, subsequently not 
modifiable/deletable, but always readable.   Kind of a database journal 
logs - it is continuously being written, sequentiall appending, but not 
circular buffer based, so that upon running out of space, logging will 
be paused in memory, and after new storage devices added to it, it will 
continue to flush out whatever is outstanding in memory.

Can ext3 / ext4 or current jbd2 be easily configured to serve this purpose?

Thanks.

Re: "Write once only but read many" filesystem

[Peter Teoh]

Thank you for your reply :-).

On Sat, Mar 22, 2008 at 11:06 PM, Jörn Engel <joern@logfs.org> wrote:
> On Sat, 22 March 2008 22:52:12 +0800, Peter Teoh wrote:
>  >
>  > what are the difference in terms of final features provided by these
>  > two different filesystem?   what is this "garbage collection"?   u
>  > still have features like creating different directories, and creating
>  > different files, and writing the files?   How about setting the file
>  > attributes...it should be set before writing right (so that after
>  > writing and handle is closed it becomes permanently not
>  > modifiable)..but creating a subdirectory below the current dir should
>  > be possible right (even after closing the previous directory)?
>
>  Your requirements aren't quite clear to me.  Do you want the complete
>  filesystem to be read-only after being written once?

YES....

>   Or do you want individual files/directories to be immutable - chattr?

chattr is not good enough, as root can still modify it.   So if
current feature is not there, then some small development may be
needed.

>  And in either case, what problem do you want to solve with a read-only filesystem?

Simple:   i want to record down everything that a user does, or a
database does, or any applications running - just record down its
state permanently securely into the filesystem, knowing that for sure,
there is not way to modify the data, short of recreating the
filesystem again.    Sound logical?   Or is there any loophole in this
concept?

In summary, are there any strong demand for such a concept/filesystem?
  I may take the plunge to implementing it, if justfiable and
everybody is interested..:-)...

-- 
Regards,
Peter Teoh
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: "Write once only but read many" filesystem

[Jörn Engel]

On Sat, 22 March 2008 23:55:53 +0800, Peter Teoh wrote:
> 
> >   Or do you want individual files/directories to be immutable - chattr?
> 
> chattr is not good enough, as root can still modify it.   So if
> current feature is not there, then some small development may be
> needed.
> 
> >  And in either case, what problem do you want to solve with a read-only filesystem?
> 
> Simple:   i want to record down everything that a user does, or a
> database does, or any applications running - just record down its
> state permanently securely into the filesystem, knowing that for sure,
> there is not way to modify the data, short of recreating the
> filesystem again.    Sound logical?   Or is there any loophole in this
> concept?

The loophole is called root.  In a normal setup, root can do anything,
including writing directly to the device your filesystem resides in,
writing to kernel memory, etc.

It may be rather inconvenient to change a filesystem by writing to the
block device, but far from impossible.  If you want to make such changes
impossible, you are facing an uphill battle that I personally don't care
about.  And if inconvenience is good enough, wouldn't chattr be
sufficiently inconvenient?

Jörn

-- 
Victory in war is not repetitious.
-- Sun Tzu
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: "Write once only but read many" filesystem

[Scott Lovenberg]

Jörn Engel wrote:
> On Sat, 22 March 2008 23:55:53 +0800, Peter Teoh wrote:
>>>   Or do you want individual files/directories to be immutable - chattr?
>> chattr is not good enough, as root can still modify it.   So if
>> current feature is not there, then some small development may be
>> needed.
>>
>>>  And in either case, what problem do you want to solve with a read-only filesystem?
>> Simple:   i want to record down everything that a user does, or a
>> database does, or any applications running - just record down its
>> state permanently securely into the filesystem, knowing that for sure,
>> there is not way to modify the data, short of recreating the
>> filesystem again.    Sound logical?   Or is there any loophole in this
>> concept?
> 
> The loophole is called root.  In a normal setup, root can do anything,
> including writing directly to the device your filesystem resides in,
> writing to kernel memory, etc.
> 
> It may be rather inconvenient to change a filesystem by writing to the
> block device, but far from impossible.  If you want to make such changes
> impossible, you are facing an uphill battle that I personally don't care
> about.  And if inconvenience is good enough, wouldn't chattr be
> sufficiently inconvenient?
> 
> Jörn
> 

How about mounting an isofs via loopback?  This has the added benefit of 
being ready to be exported to disc.  You can make it with mkisofs on a 
directory structure and mount it to the tree with a normal mount(1).  If 
it asks for fs type on mount, I think its 'iso9660'.
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: "Write once only but read many" filesystem

[Peter Teoh]

[-- Attachment #1: Type: text/html, Size: 5863 bytes --]

[-- Attachment #2: Type: text/plain, Size: 144 bytes --]

_______________________________________________
Ext3-users mailing list
Ext3-users@redhat.com
https://www.redhat.com/mailman/listinfo/ext3-users