Re: [PATCH] cramfs is ro only, so honour this in inode->mode

[Doug McNaught]

"Albert D. Cahalan" <[EMAIL PROTECTED]> writes:

> Doug writes:
> > bash-2.03$ cd /tmp
> > bash-2.03$ cat >foo
> > This is a test.
> > bash-2.03$ chmod u-r foo
> 
> No, you zeroed the owner's read bit. When the bit isn't
> implemented it must be always set.
> 
> By "(owner may read own files)" I refer to what happens
> after you steal the bit, causing it to always appear set.

Ahh, OK, thanks for the clarification.

-Doug
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] cramfs is ro only, so honour this in inode->mode

[Albert D. Cahalan]

Doug writes:
> "Albert D. Cahalan" <[EMAIL PROTECTED]> writes:

>> If you need to steal a bit, grab one that won't hurt.
>> Take the owner's read bit. (owner may read own files)
>
> Er,
>
> bash-2.03$ cd /tmp
> bash-2.03$ cat >foo
> This is a test.
> bash-2.03$ chmod u-r foo

No, you zeroed the owner's read bit. When the bit isn't
implemented it must be always set.

By "(owner may read own files)" I refer to what happens
after you steal the bit, causing it to always appear set.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] cramfs is ro only, so honour this in inode->mode

[Doug McNaught]

"Albert D. Cahalan" <[EMAIL PROTECTED]> writes:

> Shane Nay writes:
> 
> > but the bits are useless in the "normal interpretation" of it,
> ...
> > But then you pull out the write bits,
> 
> If you need to steal a bit, grab one that won't hurt.
> Take the owner's read bit. (owner may read own files)

Er,

bash-2.03$ cd /tmp
bash-2.03$ cat >foo
This is a test.
bash-2.03$ chmod u-r foo
bash-2.03$ cat foo
cat: foo: Permission denied
bash-2.03$ ls -l foo
--w-r--r--1 doug doug   16 Jan  9 09:16 foo
bash-2.03$ 

This is Linux 2.4.0.

-Doug
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] cramfs is ro only, so honour this in inode->mode

[Albert D. Cahalan]

Shane Nay writes:

> but the bits are useless in the "normal interpretation" of it,
...
> But then you pull out the write bits,

If you need to steal a bit, grab one that won't hurt.
Take the owner's read bit. (owner may read own files)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] cramfs is ro only, so honour this in inode-mode

[Albert D. Cahalan]

Shane Nay writes:

 but the bits are useless in the "normal interpretation" of it,
...
 But then you pull out the write bits,

If you need to steal a bit, grab one that won't hurt.
Take the owner's read bit. (owner may read own files)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] cramfs is ro only, so honour this in inode-mode

[Doug McNaught]

"Albert D. Cahalan" [EMAIL PROTECTED] writes:

 Shane Nay writes:
 
  but the bits are useless in the "normal interpretation" of it,
 ...
  But then you pull out the write bits,
 
 If you need to steal a bit, grab one that won't hurt.
 Take the owner's read bit. (owner may read own files)

Er,

bash-2.03$ cd /tmp
bash-2.03$ cat foo
This is a test.
bash-2.03$ chmod u-r foo
bash-2.03$ cat foo
cat: foo: Permission denied
bash-2.03$ ls -l foo
--w-r--r--1 doug doug   16 Jan  9 09:16 foo
bash-2.03$ 

This is Linux 2.4.0.

-Doug
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] cramfs is ro only, so honour this in inode-mode

[Albert D. Cahalan]

Doug writes:
 "Albert D. Cahalan" [EMAIL PROTECTED] writes:

 If you need to steal a bit, grab one that won't hurt.
 Take the owner's read bit. (owner may read own files)

 Er,

 bash-2.03$ cd /tmp
 bash-2.03$ cat foo
 This is a test.
 bash-2.03$ chmod u-r foo

No, you zeroed the owner's read bit. When the bit isn't
implemented it must be always set.

By "(owner may read own files)" I refer to what happens
after you steal the bit, causing it to always appear set.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] cramfs is ro only, so honour this in inode-mode

[Doug McNaught]

"Albert D. Cahalan" [EMAIL PROTECTED] writes:

 Doug writes:
  bash-2.03$ cd /tmp
  bash-2.03$ cat foo
  This is a test.
  bash-2.03$ chmod u-r foo
 
 No, you zeroed the owner's read bit. When the bit isn't
 implemented it must be always set.
 
 By "(owner may read own files)" I refer to what happens
 after you steal the bit, causing it to always appear set.

Ahh, OK, thanks for the clarification.

-Doug
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] cramfs is ro only, so honour this in inode->mode

[Linus Torvalds]

On Tue, 9 Jan 2001, Rusty Russell wrote:
> In message <[EMAIL PROTECTED]> you
>  write:
> > I've been thinking of doing a cramfs2, and the only thing I'd change is
> > (a) slightly bigger blocksize (maybe 8k or 16k) and (b) re-order the
> > meta-data and the real data so that I could easily compress the metadata
> > too. cramfs doesn't have any traditional meta-data (no bitmap blocks or
> > anything like that), but it wouldn't be that hard to put the directory
> > structure in the page cache and just compress the directories the same way
> > the real data is compressed.
> 
> And you'd still be worse than compressed loopback w/32k blocks, and
> more complex.  Now most of the loopback bugs seem fixed in 2.4, I'll
> port the cloop stuff, and we can compare.

If you compare, make sure that you don't compare the way some people seem
to compare. They see how well the ext2 image compresses, and ignore the
fact that the ext2 image itself has a lot of extraneous stuff (alignment,
bitmaps, very compressible meta-data etc).

The only valid comparison is how big the actual image file is for the same
trees. Also, you should take into account the size of the ext2 module and
cloop. I don't think you'd win.

Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] cramfs is ro only, so honour this in inode->mode

[Rusty Russell]

In message <[EMAIL PROTECTED]> you
 write:
> I've been thinking of doing a cramfs2, and the only thing I'd change is
> (a) slightly bigger blocksize (maybe 8k or 16k) and (b) re-order the
> meta-data and the real data so that I could easily compress the metadata
> too. cramfs doesn't have any traditional meta-data (no bitmap blocks or
> anything like that), but it wouldn't be that hard to put the directory
> structure in the page cache and just compress the directories the same way
> the real data is compressed.

And you'd still be worse than compressed loopback w/32k blocks, and
more complex.  Now most of the loopback bugs seem fixed in 2.4, I'll
port the cloop stuff, and we can compare.

Time to stop this cramfs madness!
Rusty.
--
http://linux.conf.au The Linux conference Australia needed.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] cramfs is ro only, so honour this in inode->mode

[Linus Torvalds]

On Mon, 8 Jan 2001, Ingo Oeser wrote:

> On Mon, Jan 08, 2001 at 12:13:39PM +, Shane Nay wrote:
> > This may not initially seem like such a great thing..., but imagine a base 
> > distro being distributed as a cramfs file.  Copy the thing over to your HD 
> > and you're done, otherwise the distro packaging has to keep track of 
> > permisions for each file, etc.
> 
> You can use (GNU-)tar for this. It even keeps track of other bits like
> ext2fs attributes, AFAIK.

Ehh.. And how were you going to mount it?

The advantage of cramfs is that you can make a cramfs CD-ROM, and you can
_run_ off that CD while you unpack it to your harddisk.

Using "tar" is not very practical. Doing a "tarfs" is probably not that
bad, but doing a "compressed-tar-fs" is a horrible pain in the neck
without big double buffers etc.

The advantage of cramfs is that it actually is a reasonably efficient
filesystem - becasue of the fairly small compression block-size it doesn't
compress as well as doing a bzip2 on a tar-file, but that small
compression block is also what makes random-access easy. And that's what
makes it easy to use cramfs as a "live" filesystem, very much unlike some
compressed tar-balls.

I've been thinking of doing a cramfs2, and the only thing I'd change is
(a) slightly bigger blocksize (maybe 8k or 16k) and (b) re-order the
meta-data and the real data so that I could easily compress the metadata
too. cramfs doesn't have any traditional meta-data (no bitmap blocks or
anything like that), but it wouldn't be that hard to put the directory
structure in the page cache and just compress the directories the same way
the real data is compressed.

Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] cramfs is ro only, so honour this in inode->mode

[Linus Torvalds]

On Mon, 8 Jan 2001, Ingo Oeser wrote:
> 
> cramfs is a read-only fs. So we should honour that in inode->mode to
> avoid confusion of programs.

No no no. This breaks device nodes etc quite badly.

A change to mkcramfs might be fine - but it has to conditionalize on the
file being a regular file. Not a blanket "everything is read-only".

Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] cramfs is ro only, so honour this in inode->mode

[Ingo Oeser]

On Mon, Jan 08, 2001 at 08:42:35AM -0500, Alexander Viro wrote:
> If program considers these bits of st_mode as indication of ability
> to write into file - program is buggy and should be fixed. Regardless
> of cramfs.

Ok, point taken.

I fixed the generation of the tree to be crammed into the cramfs
image instead. Same code simplification without uglyfication of
the kernel ;-)

Thanks & Regards

Ingo Oeser
-- 
10.+11.03.2001 - 3. Chemnitzer LinuxTag 
    come and join the fun   
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] cramfs is ro only, so honour this in inode->mode

[Shane Nay]

Ingo,

> You can use (GNU-)tar for this. It even keeps track of other bits like
> ext2fs attributes, AFAIK.

True..., but cramfs is acting like a mountable (tar czvf) because of the 
compressed pages.  Seems redundant to have a tar on top of what is basically 
a segmented tar with frontal indexing (read inodes).

> > On the other hand..., maybe I'm being "selfish", and this is the right
> > way to go. You never write to it, so why track the write bits?
>
> Yes, I would consider this "selfish" ;-)

Maybe :), that's why I mentioned it.

> > (One answer is maybe later we can create a writable cramfs, but
> > oh well)
>
> This could then be solved with union mount and cramfs mount over
> ramfs or any other writable Unix style fs.
>
> Then we might need W bits, but currently they disturb things like
> "test" and the perl equivalent, which is quite annoying and
> complexifies code.  (Yes, I'm selfish too ;-))

Simplifying code is a good objective..., but we've already got the bits 
there, and actually when you look at the patch it's adding complexity, not 
subtracting from it.  (Adding additional operations on the fetch of every 
inode..., plus wholesale stealing bits from operational mode of a filesystem, 
but the bits are useless in the "normal interpretation" of it, so I see your 
point)  I guess the part that bugs me is you make a filesystem out of a 
directory sub-structure expecting a 1-1 relationship of the data in the 
original directory sub-strucure, and the interpretation of your cramfs 
filesystem.  But then you pull out the write bits, and that 1-1 relationship 
is gone.  (I can only see my particular case, but there are probably others 
this disturbs)

Thanks,
Shane Nay
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] cramfs is ro only, so honour this in inode->mode

[Alexander Viro]

On Mon, 8 Jan 2001, Ingo Oeser wrote:

> Then we might need W bits, but currently they disturb things like
> "test" and the perl equivalent, which is quite annoying and
> complexifies code.  (Yes, I'm selfish too ;-))

Huh??? Consider write-protected floppy. What, you mean that it also
should magically change mode of everything? Ditto for any fs mounted r/o.

If program considers these bits of st_mode as indication of ability
to write into file - program is buggy and should be fixed. Regardless
of cramfs.

> See what Linus and Al think about this.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] cramfs is ro only, so honour this in inode->mode

[Ingo Oeser]

On Mon, Jan 08, 2001 at 12:13:39PM +, Shane Nay wrote:
> This may not initially seem like such a great thing..., but imagine a base 
> distro being distributed as a cramfs file.  Copy the thing over to your HD 
> and you're done, otherwise the distro packaging has to keep track of 
> permisions for each file, etc.

You can use (GNU-)tar for this. It even keeps track of other bits like
ext2fs attributes, AFAIK.

> On the other hand..., maybe I'm being "selfish", and this is the right way to 
> go. You never write to it, so why track the write bits?

Yes, I would consider this "selfish" ;-)

> (One answer is maybe later we can create a writable cramfs, but
> oh well)

This could then be solved with union mount and cramfs mount over
ramfs or any other writable Unix style fs.

Then we might need W bits, but currently they disturb things like
"test" and the perl equivalent, which is quite annoying and
complexifies code.  (Yes, I'm selfish too ;-))

See what Linus and Al think about this.

Regards

Ingo Oeser
-- 
10.+11.03.2001 - 3. Chemnitzer LinuxTag 
    come and join the fun   
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] cramfs is ro only, so honour this in inode->mode

[Shane Nay]

Ingo,
> cramfs is a read-only fs. So we should honour that in inode->mode
> to avoid confusion of programs.
>
> My isofs shows this too, so I think I'm right deleting the write
> permissions in the inode. May be we should change it in
> mkcramfs (too).
>
> I don't know what POSIX says about RO fs, but I can't find any
> real sense in having W permissions for an RO fs.

The only sense I can derive from it is the situation that I'm in.  We use 
cramfs partitions for lots of stuff, but one of them is to hold mirrors of 
the "default" configuration of the user-area of our device.  (Flash)  It 
makes it easy to just copy over the base partitions knowing the permisions 
will stick right.

This may not initially seem like such a great thing..., but imagine a base 
distro being distributed as a cramfs file.  Copy the thing over to your HD 
and you're done, otherwise the distro packaging has to keep track of 
permisions for each file, etc.

On the other hand..., maybe I'm being "selfish", and this is the right way to 
go.  You never write to it, so why track the write bits?  (One answer is 
maybe later we can create a writable cramfs, but oh well)  Lord knows I could 
use a few extra bits in the cramfs inode (Using sticky bit to denote XIP 
mode binaries right now..., such a hack)

Thanks,
Shane Nay.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

[PATCH] cramfs is ro only, so honour this in inode->mode

[Ingo Oeser]

Hi Linus,
hi all,

cramfs is a read-only fs. So we should honour that in inode->mode
to avoid confusion of programs.

My isofs shows this too, so I think I'm right deleting the write
permissions in the inode. May be we should change it in
mkcramfs (too).

I don't know what POSIX says about RO fs, but I can't find any
real sense in having W permissions for an RO fs.

The patch:
--- linux-2.4.0/fs/cramfs/inode.c.orig  Fri Dec 29 23:07:57 2000
+++ linux-2.4.0/fs/cramfs/inode.c   Mon Jan  8 13:04:37 2001
@@ -37,7 +37,7 @@
struct inode * inode = new_inode(sb);

if (inode) {
-   inode->i_mode = cramfs_inode->mode;
+   inode->i_mode = cramfs_inode->mode & ~ S_IWUGO;
inode->i_uid = cramfs_inode->uid;
inode->i_size = cramfs_inode->size;
inode->i_gid = cramfs_inode->gid;

Regards

Ingo Oeser
-- 
10.+11.03.2001 - 3. Chemnitzer LinuxTag 
    come and join the fun   
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

[PATCH] cramfs is ro only, so honour this in inode-mode

[Ingo Oeser]

Hi Linus,
hi all,

cramfs is a read-only fs. So we should honour that in inode-mode
to avoid confusion of programs.

My isofs shows this too, so I think I'm right deleting the write
permissions in the inode. May be we should change it in
mkcramfs (too).

I don't know what POSIX says about RO fs, but I can't find any
real sense in having W permissions for an RO fs.

The patch:
--- linux-2.4.0/fs/cramfs/inode.c.orig  Fri Dec 29 23:07:57 2000
+++ linux-2.4.0/fs/cramfs/inode.c   Mon Jan  8 13:04:37 2001
@@ -37,7 +37,7 @@
struct inode * inode = new_inode(sb);

if (inode) {
-   inode-i_mode = cramfs_inode-mode;
+   inode-i_mode = cramfs_inode-mode  ~ S_IWUGO;
inode-i_uid = cramfs_inode-uid;
inode-i_size = cramfs_inode-size;
inode-i_gid = cramfs_inode-gid;

Regards

Ingo Oeser
-- 
10.+11.03.2001 - 3. Chemnitzer LinuxTag http://www.tu-chemnitz.de/linux/tag
come and join the fun   
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] cramfs is ro only, so honour this in inode-mode

[Shane Nay]

Ingo,
 cramfs is a read-only fs. So we should honour that in inode-mode
 to avoid confusion of programs.

 My isofs shows this too, so I think I'm right deleting the write
 permissions in the inode. May be we should change it in
 mkcramfs (too).

 I don't know what POSIX says about RO fs, but I can't find any
 real sense in having W permissions for an RO fs.

The only sense I can derive from it is the situation that I'm in.  We use 
cramfs partitions for lots of stuff, but one of them is to hold mirrors of 
the "default" configuration of the user-area of our device.  (Flash)  It 
makes it easy to just copy over the base partitions knowing the permisions 
will stick right.

This may not initially seem like such a great thing..., but imagine a base 
distro being distributed as a cramfs file.  Copy the thing over to your HD 
and you're done, otherwise the distro packaging has to keep track of 
permisions for each file, etc.

On the other hand..., maybe I'm being "selfish", and this is the right way to 
go.  You never write to it, so why track the write bits?  (One answer is 
maybe later we can create a writable cramfs, but oh well)  Lord knows I could 
use a few extra bits in the cramfs inode (Using sticky bit to denote XIP 
mode binaries right now..., such a hack)

Thanks,
Shane Nay.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] cramfs is ro only, so honour this in inode-mode

[Ingo Oeser]

On Mon, Jan 08, 2001 at 12:13:39PM +, Shane Nay wrote:
 This may not initially seem like such a great thing..., but imagine a base 
 distro being distributed as a cramfs file.  Copy the thing over to your HD 
 and you're done, otherwise the distro packaging has to keep track of 
 permisions for each file, etc.

You can use (GNU-)tar for this. It even keeps track of other bits like
ext2fs attributes, AFAIK.

 On the other hand..., maybe I'm being "selfish", and this is the right way to 
 go. You never write to it, so why track the write bits?

Yes, I would consider this "selfish" ;-)

 (One answer is maybe later we can create a writable cramfs, but
 oh well)

This could then be solved with union mount and cramfs mount over
ramfs or any other writable Unix style fs.

Then we might need W bits, but currently they disturb things like
"test" and the perl equivalent, which is quite annoying and
complexifies code.  (Yes, I'm selfish too ;-))

See what Linus and Al think about this.

Regards

Ingo Oeser
-- 
10.+11.03.2001 - 3. Chemnitzer LinuxTag http://www.tu-chemnitz.de/linux/tag
come and join the fun   
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] cramfs is ro only, so honour this in inode-mode

[Alexander Viro]

On Mon, 8 Jan 2001, Ingo Oeser wrote:

 Then we might need W bits, but currently they disturb things like
 "test" and the perl equivalent, which is quite annoying and
 complexifies code.  (Yes, I'm selfish too ;-))

Huh??? Consider write-protected floppy. What, you mean that it also
should magically change mode of everything? Ditto for any fs mounted r/o.

If program considers these bits of st_mode as indication of ability
to write into file - program is buggy and should be fixed. Regardless
of cramfs.

 See what Linus and Al think about this.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] cramfs is ro only, so honour this in inode-mode

[Shane Nay]

Ingo,

 You can use (GNU-)tar for this. It even keeps track of other bits like
 ext2fs attributes, AFAIK.

True..., but cramfs is acting like a mountable (tar czvf) because of the 
compressed pages.  Seems redundant to have a tar on top of what is basically 
a segmented tar with frontal indexing (read inodes).

  On the other hand..., maybe I'm being "selfish", and this is the right
  way to go. You never write to it, so why track the write bits?

 Yes, I would consider this "selfish" ;-)

Maybe :), that's why I mentioned it.

  (One answer is maybe later we can create a writable cramfs, but
  oh well)

 This could then be solved with union mount and cramfs mount over
 ramfs or any other writable Unix style fs.

 Then we might need W bits, but currently they disturb things like
 "test" and the perl equivalent, which is quite annoying and
 complexifies code.  (Yes, I'm selfish too ;-))

Simplifying code is a good objective..., but we've already got the bits 
there, and actually when you look at the patch it's adding complexity, not 
subtracting from it.  (Adding additional operations on the fetch of every 
inode..., plus wholesale stealing bits from operational mode of a filesystem, 
but the bits are useless in the "normal interpretation" of it, so I see your 
point)  I guess the part that bugs me is you make a filesystem out of a 
directory sub-structure expecting a 1-1 relationship of the data in the 
original directory sub-strucure, and the interpretation of your cramfs 
filesystem.  But then you pull out the write bits, and that 1-1 relationship 
is gone.  (I can only see my particular case, but there are probably others 
this disturbs)

Thanks,
Shane Nay
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] cramfs is ro only, so honour this in inode-mode

[Ingo Oeser]

On Mon, Jan 08, 2001 at 08:42:35AM -0500, Alexander Viro wrote:
 If program considers these bits of st_mode as indication of ability
 to write into file - program is buggy and should be fixed. Regardless
 of cramfs.

Ok, point taken.

I fixed the generation of the tree to be crammed into the cramfs
image instead. Same code simplification without uglyfication of
the kernel ;-)

Thanks  Regards

Ingo Oeser
-- 
10.+11.03.2001 - 3. Chemnitzer LinuxTag http://www.tu-chemnitz.de/linux/tag
come and join the fun   
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] cramfs is ro only, so honour this in inode-mode

[Linus Torvalds]

On Mon, 8 Jan 2001, Ingo Oeser wrote:
 
 cramfs is a read-only fs. So we should honour that in inode-mode to
 avoid confusion of programs.

No no no. This breaks device nodes etc quite badly.

A change to mkcramfs might be fine - but it has to conditionalize on the
file being a regular file. Not a blanket "everything is read-only".

Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] cramfs is ro only, so honour this in inode-mode

[Linus Torvalds]

On Mon, 8 Jan 2001, Ingo Oeser wrote:

 On Mon, Jan 08, 2001 at 12:13:39PM +, Shane Nay wrote:
  This may not initially seem like such a great thing..., but imagine a base 
  distro being distributed as a cramfs file.  Copy the thing over to your HD 
  and you're done, otherwise the distro packaging has to keep track of 
  permisions for each file, etc.
 
 You can use (GNU-)tar for this. It even keeps track of other bits like
 ext2fs attributes, AFAIK.

Ehh.. And how were you going to mount it?

The advantage of cramfs is that you can make a cramfs CD-ROM, and you can
_run_ off that CD while you unpack it to your harddisk.

Using "tar" is not very practical. Doing a "tarfs" is probably not that
bad, but doing a "compressed-tar-fs" is a horrible pain in the neck
without big double buffers etc.

The advantage of cramfs is that it actually is a reasonably efficient
filesystem - becasue of the fairly small compression block-size it doesn't
compress as well as doing a bzip2 on a tar-file, but that small
compression block is also what makes random-access easy. And that's what
makes it easy to use cramfs as a "live" filesystem, very much unlike some
compressed tar-balls.

I've been thinking of doing a cramfs2, and the only thing I'd change is
(a) slightly bigger blocksize (maybe 8k or 16k) and (b) re-order the
meta-data and the real data so that I could easily compress the metadata
too. cramfs doesn't have any traditional meta-data (no bitmap blocks or
anything like that), but it wouldn't be that hard to put the directory
structure in the page cache and just compress the directories the same way
the real data is compressed.

Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] cramfs is ro only, so honour this in inode-mode

[Rusty Russell]

In message [EMAIL PROTECTED] you
 write:
 I've been thinking of doing a cramfs2, and the only thing I'd change is
 (a) slightly bigger blocksize (maybe 8k or 16k) and (b) re-order the
 meta-data and the real data so that I could easily compress the metadata
 too. cramfs doesn't have any traditional meta-data (no bitmap blocks or
 anything like that), but it wouldn't be that hard to put the directory
 structure in the page cache and just compress the directories the same way
 the real data is compressed.

And you'd still be worse than compressed loopback w/32k blocks, and
more complex.  Now most of the loopback bugs seem fixed in 2.4, I'll
port the cloop stuff, and we can compare.

Time to stop this cramfs madness!
Rusty.
--
http://linux.conf.au The Linux conference Australia needed.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] cramfs is ro only, so honour this in inode-mode

[Linus Torvalds]

On Tue, 9 Jan 2001, Rusty Russell wrote:
 In message [EMAIL PROTECTED] you
  write:
  I've been thinking of doing a cramfs2, and the only thing I'd change is
  (a) slightly bigger blocksize (maybe 8k or 16k) and (b) re-order the
  meta-data and the real data so that I could easily compress the metadata
  too. cramfs doesn't have any traditional meta-data (no bitmap blocks or
  anything like that), but it wouldn't be that hard to put the directory
  structure in the page cache and just compress the directories the same way
  the real data is compressed.
 
 And you'd still be worse than compressed loopback w/32k blocks, and
 more complex.  Now most of the loopback bugs seem fixed in 2.4, I'll
 port the cloop stuff, and we can compare.

If you compare, make sure that you don't compare the way some people seem
to compare. They see how well the ext2 image compresses, and ignore the
fact that the ext2 image itself has a lot of extraneous stuff (alignment,
bitmaps, very compressible meta-data etc).

The only valid comparison is how big the actual image file is for the same
trees. Also, you should take into account the size of the ext2 module and
cloop. I don't think you'd win.

Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/