Jan Harkes wrote:
>
> On Tue, Mar 27, 2001 at 01:57:42PM -0600, Jesse Pollard wrote:
> > > Using similar numbers as presented. If we are working our way through
> > > every single block in a Pentabyte filesystem, and the blocksize is 512
> > > bytes. Then the 1us in extra CPU cycles because of 64
Ion Badulescu wrote:
> Are you being deliberately insulting, "L", or are you one of those users
> who bitch and scream for features they *need* at *any cost*, and who
> have never even opened up the book for Computer Architecture 101?
---
Sorry, I was borderline insulting. I'm getting pre
Ion Badulescu wrote:
> Yes, there are millions of 32-bit systems in use today. They do their job
> just fine with the 32-bit device support we have right now. Do you really
> want to penalize them *all* for the sake of the few idiotic sysadmins who
> want multi-TB storage on their 32-bit system?
-
Matthew Wilcox wrote:
>
> On Mon, Mar 26, 2001 at 08:39:21AM -0800, LA Walsh wrote:
> > I vaguely remember a discussion about this a few months back.
> > If I remember, the reasoning was it would unnecessarily slow
> > down smaller systems that would never have block
I vaguely remember a discussion about this a few months back.
If I remember, the reasoning was it would unnecessarily slow
down smaller systems that would never have block devices in
the 4-28T range attached.
However, isn't it possible there will continue to be a series
of P-IV,V,VI,VII ...etc,
Also, more widely, any of the new op fields the blk ops, the new inode
fields,
getattr/setattr, etc...descriptions would be "real keen":-)
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Ingo Oeser
> Sent: Tuesday, February 06, 2001 4:48 AM
> To
> -Original Message-
> From: Robert Watson [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, January 11, 2001 9:17 AM
> To: LA Walsh
> Cc: [EMAIL PROTECTED];
> [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: ext_attr overlaps
>
>
>
> If you're ref
Behalf Of
> Christoph Hellwig
> Sent: Thursday, January 11, 2001 12:35 AM
> To: LA Walsh
> Cc: [EMAIL PROTECTED];
> [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: [Linux-privs-discuss] ext_attr overlaps
>
>
> On Wed, Jan 10, 2001 at 03:27:27PM -0800, LA Walsh wrote:
&
I notice that for the basic posix families, mac, cap, acl, and info,
all share structure "function_[get/set]_[file/fd]". It seems the
logical place for this is in ext_attr handling.
I.e. -- when any of the families are called with a pathname or fd, it
seems the first resolv to an inode, then a
> just parse the data page, looking for your options, in do_remount_sb,
> and read_super. you should have everything you need at that point to
> set up your internal data structures.
---
Right now we have a separate place for Mount parameters (16 flags) that
are fs-independent. The point
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
> Matthew Wilcox
> Sent: Friday, January 05, 2001 3:16 PM
> To: LA Walsh
> Cc: Andreas Dilger; Matthew Kirkwood; [EMAIL PROTECTED];
> [EMAIL PROTECTED]
> Subject: Re: More bette
> -Original Message-
> From: Andreas Dilger
> > > mount("/dev/fd0", "/mnt", "vfat", 0, "uid=503");
> > >
> > ---
> > *Bingo*. That's the idea of the default mac label. For example I
> > want to mount a CD. The CD comes from Michael who is level 5
> cleared. When
> > I mount it on
> -Original Message-
> From: Matthew Kirkwood
> We already have an analogue of this, I think. FAT-based
> filesystems have a mount option to set the uid of the
> files (I think).
>
> If mount(8) supported it, it could turn:
>
> # mount -t vfat -o uid=law /dev/fd0 /mnt
>
> into
>
> mount
> -Original Message-
> From: Nathan Scott [mailto:[EMAIL PROTECTED]]
> Sent: Friday, January 05, 2001 7:42 AM
> To: LA Walsh
> Cc: [EMAIL PROTECTED]
> Subject: Re: More better in mount(2)
>
>
> hi Linda,
>
> Each filesystem can parse its own options
> -Original Message-
> From: [EMAIL PROTECTED]
>
> > I'd like to be able to pass through a fs-independent 'data'
> field to mount.
> > I'm thinking if a mount flag is passed in (say MS_EXTRA = 16384
> in fs.h),
> > then a 6th parameter is expected.
>
> Ugly. We already have an options par
> Linda Walsh writes:
> > I'd like to be able to pass through a fs-independent 'data' field to
mount.
>
> Why not simply use the existing mount options mechanism, and have the
> filesystem parse the options. You would need to have the options as
> strings.
---
Would that be advisable for
I'd like to be able to pass through a fs-independent 'data' field to mount.
I'm thinking if a mount flag is passed in (say MS_EXTRA = 16384 in fs.h),
then
a 6th parameter is expected. That 6th parameter would be a list of the
form:
|16-bit signed data length|16-bit signed record type|data|.
A r
I notice many places in open.c where 'lock_kernel()' has been dropped in
2.4. There are still a few places. Should there be a separate
file-sub-system
lock, perhaps later evolving into a /per filesystem lock?
Under what circumstances in the file-system code does one still have
to (or should) l
> And not all kernels have sym link redirects ... Oh wait! ...
> NO KERNELS[1] do sym link redirects for tmp.
---
So if I make /tmp a symlink to /var/tmp, it won't work in
any kernel? Um. Hmmm.
>
> Sure you can argue that it'd be more work to fix the problem the
> right way, but th
> Not really, since Medusa in-kernel part caches the constable
> responses. This
> prevents excessive user-space queries. In my experience
> Medusa-overhead was
> well under 3% CPU time.
---
Ok, I may be living in fantasy land, but to my mind .3% might be
acceptable. 3% seems too noti
> The simple implementation would require that the directories be recreated.
^
---
This should have been 'precreated'.
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a mes
We were thinking about ways that users could be given their private
copy of various shared directories like /tmp, /var/tmp, etc.
To this end, we banged heads together and came up with an idea --
suppose the linux pathname resolution routines could be compiled
with an option to do simple substitu
> On Tue, Nov 07, 2000 at 06:37:13AM -0500, [EMAIL PROTECTED] wrote:
> > Hi all. I have a need to stretch a file (rapidly) to a new
> > allocated size, but do not want to actually write data by
> > the current machine at the current time (I just need there to
> > be allocated blocks).
>
> Be awa
23 matches
Mail list logo
