> Calling pathconf with a symlink is not defined.
The Austin draft requires pathconf to follow symlinks.
-
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/
Al Viro writes:
> Andreas Dilger wrote:
> > Actually, this is wrong. The ext2 inode limit is 2^32 512-byte sectors,
> > not 2^32 blocksize blocks. Yes this is a wart and Ted wants to fix it, as
>
> ??? Where? Oh, wait... ->i_blocks? I'ld rather refuse to grow past 2^32 -
> sparse files can
On Mon, 8 Jan 2001, Andreas Dilger wrote:
> Actually, this is wrong. The ext2 inode limit is 2^32 512-byte sectors,
> not 2^32 blocksize blocks. Yes this is a wart and Ted wants to fix it, as
??? Where? Oh, wait... ->i_blocks? I'ld rather refuse to grow past 2^32 -
sparse files can
Al Viro writes:
> No, it doesn't. s/$/while(bh != head);/, indeed. Sorry about that -
> cut-and-waste when I did rediff to 2.4.0. Corrected patch follows:
>
> diff -urN S0-AC4/fs/ext2/super.c S0-AC4-fixes/fs/ext2/super.c
> --- S0-AC4/fs/ext2/super.cMon Jan 8 08:46:18 2001
> +++
On Mon, 8 Jan 2001, Marc Lehmann wrote:
> On Mon, Jan 08, 2001 at 01:33:50PM -0500, Alexander Viro <[EMAIL PROTECTED]> wrote:
> > And prefix would be what? "/"? Besides, I said that you don't have
> > read permissions on /foo, not search ones.
>
> You do not need read permissions on /foo to
On Mon, Jan 08, 2001 at 01:33:50PM -0500, Alexander Viro <[EMAIL PROTECTED]> wrote:
> And prefix would be what? "/"? Besides, I said that you don't have
> read permissions on /foo, not search ones.
You do not need read permissions on /foo to make pathconf on it. This
makes sense: you are not
On Mon, Jan 08, 2001 at 01:33:50PM -0500, Alexander Viro wrote:
>
> On Mon, 8 Jan 2001, Stefan Traby wrote:
>
> > On Mon, Jan 08, 2001 at 01:22:49PM -0500, Alexander Viro wrote:
> >
> > > Here's another one: suppose that /foo is a mountpoint and you have
> > > no read permissions on it. Try to
On Mon, 8 Jan 2001, Stefan Traby wrote:
> On Mon, Jan 08, 2001 at 01:22:49PM -0500, Alexander Viro wrote:
>
> > Here's another one: suppose that /foo is a mountpoint and you have
> > no read permissions on it. Try to open the thing...
>
> I would return EACCESS.
> [EACCES]
> Search
On Mon, Jan 08, 2001 at 01:22:49PM -0500, Alexander Viro wrote:
> Here's another one: suppose that /foo is a mountpoint and you have
> no read permissions on it. Try to open the thing...
I would return EACCESS.
[EACCES]
Search permission is denied for a component of the path prefix.
On Mon, 8 Jan 2001, Stefan Traby wrote:
> Calling pathconf with a symlink is not defined. I suggest
> an implementation of "yankee doodle" for that case.
> Anyway the broken SuS standard wants that pathconf follow symlinks.
> Or how do you interpret this:
>
> [ELOOP]
>Too many
On Mon, Jan 08, 2001 at 01:05:49PM -0500, Alexander Viro wrote:
>
>
> On Mon, 8 Jan 2001, Stefan Traby wrote:
>
> > On Mon, Jan 08, 2001 at 04:01:10PM +, Alan Cox wrote:
> > > > I prefer SuS fpathconf(), pathconf() is just a wrapper to fpathconf();
> > >
> > > You can't implement it that
On Mon, 8 Jan 2001, Stefan Traby wrote:
> On Mon, Jan 08, 2001 at 04:01:10PM +, Alan Cox wrote:
> > > I prefer SuS fpathconf(), pathconf() is just a wrapper to fpathconf();
> >
> > You can't implement it that way in the corner cases.
>
> I reread SuSv2 again and didn't found corner
On Mon, Jan 08, 2001 at 04:01:10PM +, Alan Cox wrote:
> > I prefer SuS fpathconf(), pathconf() is just a wrapper to fpathconf();
>
> You can't implement it that way in the corner cases.
I reread SuSv2 again and didn't found corner cases.
Do you mean FIFO/pipe stuff ? I can't see the problem
> if (pos + count > inode->i_sb->s_maxbytes)
> {
> count = inode->i_sb->s_maxbytes - count;
> goto out;
> }
>
> looks funny - goto out means that new (and rather meaningless) value of
> count goes to hell. Shouldn't we remove that line and
On Mon, 8 Jan 2001, Chris Mason wrote:
>
> On Monday, January 08, 2001 10:47:41 AM -0500 Alexander Viro
> <[EMAIL PROTECTED]> wrote:
> > + do {
> > + if (buffer_mapped(bh)) {
> > + bh->b_end_io = end_buffer_io_async;
> > + atomic_inc(>b_count);
> I reread SuSv2 again and didn't found corner cases.
> Do you mean FIFO/pipe stuff ? I can't see the problem in this area.
>
> In which case is an emulation of pathconf by fpathconf impossible ?
use all your file descriptors up. Now try
-
To unsubscribe from this list: send the line
On Monday, January 08, 2001 10:47:41 AM -0500 Alexander Viro
<[EMAIL PROTECTED]> wrote:
> + do {
> + if (buffer_mapped(bh)) {
> + bh->b_end_io = end_buffer_io_async;
> + atomic_inc(>b_count);
> + set_bit(BH_Uptodate,
> I prefer SuS fpathconf(), pathconf() is just a wrapper to fpathconf();
You can't implement it that way in the corner cases.
-
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/
On Mon, Jan 08, 2001 at 02:40:45PM +, Alan Cox wrote:
> > > Why not start to fix this problem outside the funny switch/case in glibc ?
> > > The filesystem itself should able to handle this.
> >
> > Sigh... And the API would be?
>
> In SuS its pathconf()
I prefer SuS fpathconf(),
On Mon, 8 Jan 2001, Chris Mason wrote:
>
>
> On Monday, January 08, 2001 09:02:46 AM -0500 Alexander Viro
> <[EMAIL PROTECTED]> wrote:
>
> > Alan, consider applying the patch below.
> > Contents:
> [snip]
> > + do {
> > + if (buffer_mapped(bh)) {
> > +
On Monday, January 08, 2001 09:02:46 AM -0500 Alexander Viro
<[EMAIL PROTECTED]> wrote:
> Alan, consider applying the patch below.
> Contents:
[snip]
> + do {
> + if (buffer_mapped(bh)) {
> + bh->b_end_io = end_buffer_io_async;
> +
On Mon, 8 Jan 2001, Alan Cox wrote:
> > Which happens to be remarkably ugly. And it will not get better tomoorow...
>
> Its really only ugly in one way which is that you pass an int for the item
> rather than having a struct of all the data
You know as well as I do that as soon as we add it
> Which happens to be remarkably ugly. And it will not get better tomoorow...
Its really only ugly in one way which is that you pass an int for the item
rather than having a struct of all the data
Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
On Mon, 8 Jan 2001, Alan Cox wrote:
> > > Why not start to fix this problem outside the funny switch/case in glibc ?
> > > The filesystem itself should able to handle this.
> >
> > Sigh... And the API would be?
>
> In SuS its pathconf()
Which happens to be remarkably ugly. And it will not
> > Why not start to fix this problem outside the funny switch/case in glibc ?
> > The filesystem itself should able to handle this.
>
> Sigh... And the API would be?
In SuS its pathconf()
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
On Mon, 8 Jan 2001, Stefan Traby wrote:
> Because I have no knowledge on this I suggest that you and Ulrich fight
> together on a more flexible solution than the current one. I guess
> that Linus would accept this without thinking too much about it.
Unfortunately, Ulrich's taste was
Alan, consider applying the patch below.
Contents:
* recovery from failing get_block() in __block_write_full_page()
and __block_prepare_write().
* handling of partially mapped pages in generic_file_write().
* use of ->s_maxbytes in default_llseek().
* crapectomy in
On Mon, Jan 08, 2001 at 08:35:10AM -0500, Alexander Viro wrote:
> On Mon, 8 Jan 2001, Stefan Traby wrote:
> > Try 'getconf LINK_MAX /ramfs'.
> > While the result (127) is in some way SuS/POSIXLY_CORRECT,
> > it's not the truth.
> >
> > Why not start to fix this problem outside the funny
[EMAIL PROTECTED] said:
> I put it into generic_file_write. That covers most fs's it seems. The
> jffs guys are going to switch to generic_file_write soon
It's in CVS already. For 2.4, 'soon' == 'when Linus is ready to start taking
patches'
If you want it for 2.4-ac I can provide a patch
On Mon, 8 Jan 2001, Stefan Traby wrote:
> On Mon, Jan 08, 2001 at 12:26:17PM +, Alan Cox wrote:
>
> > I can put all that in the VFS so I did (right now the ext2 size calculator is
> > wrong but thats proof of concept detail). Just need to shift if over from
> > ext2/file.c
>
> Try
On Mon, Jan 08, 2001 at 12:26:17PM +, Alan Cox wrote:
> I can put all that in the VFS so I did (right now the ext2 size calculator is
> wrong but thats proof of concept detail). Just need to shift if over from
> ext2/file.c
Try 'getconf LINK_MAX /ramfs'.
While the result (127) is in some
> Umm... Details, please? Are you talking about 2^32 or about fs layout limits?
> The former may very well belong to VFS - no arguments here. The latter...
> And yes, fs layout limits are visible - for ext2 they can be as low as 2^24
> blocks.
The SuS rules require write checks
resource limit
On Mon, 8 Jan 2001, Alan Cox wrote:
> > > I put it into generic_file_write. That covers most fs's it seems. The jffs
> > > guys are going to switch to generic_file_write soon and the other fs's
> > > that dont are wacko ones I dont care about ;)
> >
> > Alan, we have to deal with
> > I put it into generic_file_write. That covers most fs's it seems. The jffs
> > guys are going to switch to generic_file_write soon and the other fs's
> > that dont are wacko ones I dont care about ;)
>
> Alan, we have to deal with get_block() failures anyway. -ENOSPC, -EDQUOT,
> not to
On Mon, 8 Jan 2001, Alan Cox wrote:
> > Alan, it doesn't work that way. Maximal size depends on the type of object,
> > for one thing. Moreover, it's not always a multiple of page size, so you
>
> Its a multiple of page size for all fs's we have but I did it in terms of
> bytes anyway
> There is code to support this in 2.4.0-ac4 -- initially I didn't like
> the way Alan had done things (I was think -EFBIG should be used only
> for LFS violations) but after some thought has decided that what he
> has makes a lot of sense.
Its based on the docs I have + a test program for the
> Alan, it doesn't work that way. Maximal size depends on the type of object,
> for one thing. Moreover, it's not always a multiple of page size, so you
Its a multiple of page size for all fs's we have but I did it in terms of
bytes anyway
> still need foo_get_block() to be aware of the problem
On Mon, 8 Jan 2001, Chris Wedgwood wrote:
> On Mon, Jan 08, 2001 at 02:56:10AM -0500, Alexander Viro wrote:
>
> Plenty. ext2, for one - e.g. with 4Kb blocks you have limit
> at 0x4010040c000 for files and 0x1 for directories. With
> 1Kb blocks the limit for files is
On Mon, 8 Jan 2001, Chris Wedgwood wrote:
On Mon, Jan 08, 2001 at 02:56:10AM -0500, Alexander Viro wrote:
Plenty. ext2, for one - e.g. with 4Kb blocks you have limit
at 0x4010040c000 for files and 0x1 for directories. With
1Kb blocks the limit for files is
Alan, it doesn't work that way. Maximal size depends on the type of object,
for one thing. Moreover, it's not always a multiple of page size, so you
Its a multiple of page size for all fs's we have but I did it in terms of
bytes anyway
still need foo_get_block() to be aware of the problem
There is code to support this in 2.4.0-ac4 -- initially I didn't like
the way Alan had done things (I was think -EFBIG should be used only
for LFS violations) but after some thought has decided that what he
has makes a lot of sense.
Its based on the docs I have + a test program for the non
On Mon, 8 Jan 2001, Alan Cox wrote:
Alan, it doesn't work that way. Maximal size depends on the type of object,
for one thing. Moreover, it's not always a multiple of page size, so you
Its a multiple of page size for all fs's we have but I did it in terms of
bytes anyway
1Kb-block
I put it into generic_file_write. That covers most fs's it seems. The jffs
guys are going to switch to generic_file_write soon and the other fs's
that dont are wacko ones I dont care about ;)
Alan, we have to deal with get_block() failures anyway. -ENOSPC, -EDQUOT,
not to mention
On Mon, 8 Jan 2001, Alan Cox wrote:
I put it into generic_file_write. That covers most fs's it seems. The jffs
guys are going to switch to generic_file_write soon and the other fs's
that dont are wacko ones I dont care about ;)
Alan, we have to deal with get_block() failures
Umm... Details, please? Are you talking about 2^32 or about fs layout limits?
The former may very well belong to VFS - no arguments here. The latter...
And yes, fs layout limits are visible - for ext2 they can be as low as 2^24
blocks.
The SuS rules require write checks
resource limit
On Mon, Jan 08, 2001 at 12:26:17PM +, Alan Cox wrote:
I can put all that in the VFS so I did (right now the ext2 size calculator is
wrong but thats proof of concept detail). Just need to shift if over from
ext2/file.c
Try 'getconf LINK_MAX /ramfs'.
While the result (127) is in some way
On Mon, 8 Jan 2001, Stefan Traby wrote:
On Mon, Jan 08, 2001 at 12:26:17PM +, Alan Cox wrote:
I can put all that in the VFS so I did (right now the ext2 size calculator is
wrong but thats proof of concept detail). Just need to shift if over from
ext2/file.c
Try 'getconf
[EMAIL PROTECTED] said:
I put it into generic_file_write. That covers most fs's it seems. The
jffs guys are going to switch to generic_file_write soon
It's in CVS already. For 2.4, 'soon' == 'when Linus is ready to start taking
patches'
If you want it for 2.4-ac I can provide a patch
On Mon, Jan 08, 2001 at 08:35:10AM -0500, Alexander Viro wrote:
On Mon, 8 Jan 2001, Stefan Traby wrote:
Try 'getconf LINK_MAX /ramfs'.
While the result (127) is in some way SuS/POSIXLY_CORRECT,
it's not the truth.
Why not start to fix this problem outside the funny switch/case in
Alan, consider applying the patch below.
Contents:
* recovery from failing get_block() in __block_write_full_page()
and __block_prepare_write().
* handling of partially mapped pages in generic_file_write().
* use of -s_maxbytes in default_llseek().
* crapectomy in
On Mon, 8 Jan 2001, Stefan Traby wrote:
Because I have no knowledge on this I suggest that you and Ulrich fight
together on a more flexible solution than the current one. I guess
that Linus would accept this without thinking too much about it.
Unfortunately, Ulrich's taste was incompatible
Why not start to fix this problem outside the funny switch/case in glibc ?
The filesystem itself should able to handle this.
Sigh... And the API would be?
In SuS its pathconf()
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
On Mon, 8 Jan 2001, Alan Cox wrote:
Why not start to fix this problem outside the funny switch/case in glibc ?
The filesystem itself should able to handle this.
Sigh... And the API would be?
In SuS its pathconf()
Which happens to be remarkably ugly. And it will not get better
On Mon, 8 Jan 2001, Alan Cox wrote:
Which happens to be remarkably ugly. And it will not get better tomoorow...
Its really only ugly in one way which is that you pass an int for the item
rather than having a struct of all the data
You know as well as I do that as soon as we add it glibc
On Monday, January 08, 2001 09:02:46 AM -0500 Alexander Viro
[EMAIL PROTECTED] wrote:
Alan, consider applying the patch below.
Contents:
[snip]
+ do {
+ if (buffer_mapped(bh)) {
+ bh-b_end_io = end_buffer_io_async;
+
On Mon, 8 Jan 2001, Chris Mason wrote:
On Monday, January 08, 2001 09:02:46 AM -0500 Alexander Viro
[EMAIL PROTECTED] wrote:
Alan, consider applying the patch below.
Contents:
[snip]
+ do {
+ if (buffer_mapped(bh)) {
+ bh-b_end_io =
I prefer SuS fpathconf(), pathconf() is just a wrapper to fpathconf();
You can't implement it that way in the corner cases.
-
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/
On Monday, January 08, 2001 10:47:41 AM -0500 Alexander Viro
[EMAIL PROTECTED] wrote:
+ do {
+ if (buffer_mapped(bh)) {
+ bh-b_end_io = end_buffer_io_async;
+ atomic_inc(bh-b_count);
+ set_bit(BH_Uptodate,
I reread SuSv2 again and didn't found corner cases.
Do you mean FIFO/pipe stuff ? I can't see the problem in this area.
In which case is an emulation of pathconf by fpathconf impossible ?
use all your file descriptors up. Now try
-
To unsubscribe from this list: send the line "unsubscribe
On Mon, 8 Jan 2001, Chris Mason wrote:
On Monday, January 08, 2001 10:47:41 AM -0500 Alexander Viro
[EMAIL PROTECTED] wrote:
+ do {
+ if (buffer_mapped(bh)) {
+ bh-b_end_io = end_buffer_io_async;
+ atomic_inc(bh-b_count);
+
if (pos + count inode-i_sb-s_maxbytes)
{
count = inode-i_sb-s_maxbytes - count;
goto out;
}
looks funny - goto out means that new (and rather meaningless) value of
count goes to hell. Shouldn't we remove that line and s/- count/-
On Mon, Jan 08, 2001 at 04:01:10PM +, Alan Cox wrote:
I prefer SuS fpathconf(), pathconf() is just a wrapper to fpathconf();
You can't implement it that way in the corner cases.
I reread SuSv2 again and didn't found corner cases.
Do you mean FIFO/pipe stuff ? I can't see the problem in
On Mon, 8 Jan 2001, Stefan Traby wrote:
On Mon, Jan 08, 2001 at 04:01:10PM +, Alan Cox wrote:
I prefer SuS fpathconf(), pathconf() is just a wrapper to fpathconf();
You can't implement it that way in the corner cases.
I reread SuSv2 again and didn't found corner cases.
Do you
On Mon, Jan 08, 2001 at 01:05:49PM -0500, Alexander Viro wrote:
On Mon, 8 Jan 2001, Stefan Traby wrote:
On Mon, Jan 08, 2001 at 04:01:10PM +, Alan Cox wrote:
I prefer SuS fpathconf(), pathconf() is just a wrapper to fpathconf();
You can't implement it that way in the
On Mon, 8 Jan 2001, Stefan Traby wrote:
Calling pathconf with a symlink is not defined. I suggest
an implementation of "yankee doodle" for that case.
Anyway the broken SuS standard wants that pathconf follow symlinks.
Or how do you interpret this:
[ELOOP]
Too many symbolic
On Mon, Jan 08, 2001 at 01:22:49PM -0500, Alexander Viro wrote:
Here's another one: suppose that /foo is a mountpoint and you have
no read permissions on it. Try to open the thing...
I would return EACCESS.
[EACCES]
Search permission is denied for a component of the path prefix.
On Mon, 8 Jan 2001, Stefan Traby wrote:
On Mon, Jan 08, 2001 at 01:22:49PM -0500, Alexander Viro wrote:
Here's another one: suppose that /foo is a mountpoint and you have
no read permissions on it. Try to open the thing...
I would return EACCESS.
[EACCES]
Search
On Mon, Jan 08, 2001 at 01:33:50PM -0500, Alexander Viro wrote:
On Mon, 8 Jan 2001, Stefan Traby wrote:
On Mon, Jan 08, 2001 at 01:22:49PM -0500, Alexander Viro wrote:
Here's another one: suppose that /foo is a mountpoint and you have
no read permissions on it. Try to open the
On Mon, Jan 08, 2001 at 01:33:50PM -0500, Alexander Viro [EMAIL PROTECTED] wrote:
And prefix would be what? "/"? Besides, I said that you don't have
read permissions on /foo, not search ones.
You do not need read permissions on /foo to make pathconf on it. This
makes sense: you are not reading
On Mon, 8 Jan 2001, Marc Lehmann wrote:
On Mon, Jan 08, 2001 at 01:33:50PM -0500, Alexander Viro [EMAIL PROTECTED] wrote:
And prefix would be what? "/"? Besides, I said that you don't have
read permissions on /foo, not search ones.
You do not need read permissions on /foo to make
Al Viro writes:
No, it doesn't. s/$/while(bh != head);/, indeed. Sorry about that -
cut-and-waste when I did rediff to 2.4.0. Corrected patch follows:
diff -urN S0-AC4/fs/ext2/super.c S0-AC4-fixes/fs/ext2/super.c
--- S0-AC4/fs/ext2/super.cMon Jan 8 08:46:18 2001
+++
On Mon, 8 Jan 2001, Andreas Dilger wrote:
Actually, this is wrong. The ext2 inode limit is 2^32 512-byte sectors,
not 2^32 blocksize blocks. Yes this is a wart and Ted wants to fix it, as
??? Where? Oh, wait... -i_blocks? I'ld rather refuse to grow past 2^32 -
sparse files can
Al Viro writes:
Andreas Dilger wrote:
Actually, this is wrong. The ext2 inode limit is 2^32 512-byte sectors,
not 2^32 blocksize blocks. Yes this is a wart and Ted wants to fix it, as
??? Where? Oh, wait... -i_blocks? I'ld rather refuse to grow past 2^32 -
sparse files can legitimately
Calling pathconf with a symlink is not defined.
The Austin draft requires pathconf to follow symlinks.
-
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/
On Sun, 7 Jan 2001, Chris Wedgwood wrote:
> On Sat, Jan 06, 2001 at 03:35:32PM +, Alan Cox wrote:
>
> BTW Al: We have another general vfs/fs problem to handle - which
> is exceeding max file sizes on limited file systems. Pretty much
> nobody is getting it right. Ext2 can be
On Sat, 6 Jan 2001, Alan Cox wrote:
> > > > Add UnlockPage(page) at the end of ramfs_writepage().
> > > Shit. You are quite fast. Works.
> >
> > Sure, especially considering the fact that patch was sent to
> > Linus about a month ago (several times, actually)... ;-/
>
> Its in all the
Alan Cox <[EMAIL PROTECTED]> writes:
> > Putting the LFS checks, & max filesize checks into the VFS sounds
> > right for 2.4.x because it fixes lots of filesystems, with just a
> > couple of lines of code.
>
> Rather more than that, and it only fixes those using generic_file_*
True. But it
> .. or we can check 'up one level' by adding another method to struct
> file_operations perhaps (gross?).
Not feasible. SOme work has to be done by the fs in certain cases. I can cover
the majority of them tho
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body
> THis means we limit all NFS file sizes to 32-bits unless we have
> NFSv3? (I assume v3 is where the 64-bit file sizes comes from? or
> does it predate that?)
NFSv2 has a 32bit file offset. Thus the largest file on NFSv2 you want to
touch is 2Gig.
Alan
-
To unsubscribe from this list: send
> Putting the LFS checks, & max filesize checks into the VFS sounds
> right for 2.4.x because it fixes lots of filesystems, with just a
> couple of lines of code.
Rather more than that, and it only fixes those using generic_file_*
-
To unsubscribe from this list: send the line "unsubscribe
Putting the LFS checks, max filesize checks into the VFS sounds
right for 2.4.x because it fixes lots of filesystems, with just a
couple of lines of code.
Rather more than that, and it only fixes those using generic_file_*
-
To unsubscribe from this list: send the line "unsubscribe
THis means we limit all NFS file sizes to 32-bits unless we have
NFSv3? (I assume v3 is where the 64-bit file sizes comes from? or
does it predate that?)
NFSv2 has a 32bit file offset. Thus the largest file on NFSv2 you want to
touch is 2Gig.
Alan
-
To unsubscribe from this list: send the
Alan Cox [EMAIL PROTECTED] writes:
Putting the LFS checks, max filesize checks into the VFS sounds
right for 2.4.x because it fixes lots of filesystems, with just a
couple of lines of code.
Rather more than that, and it only fixes those using generic_file_*
True. But it is
On Sat, 6 Jan 2001, Alan Cox wrote:
Add UnlockPage(page) at the end of ramfs_writepage().
Shit. You are quite fast. Works.
Sure, especially considering the fact that patch was sent to
Linus about a month ago (several times, actually)... ;-/
Its in all the -ac trees 8)
On Sun, 7 Jan 2001, Chris Wedgwood wrote:
On Sat, Jan 06, 2001 at 03:35:32PM +, Alan Cox wrote:
BTW Al: We have another general vfs/fs problem to handle - which
is exceeding max file sizes on limited file systems. Pretty much
nobody is getting it right. Ext2 can be
Chris Wedgwood <[EMAIL PROTECTED]> writes:
> On Sat, Jan 06, 2001 at 03:58:20PM +, Alan Cox wrote:
>
> Ext2 handles large files almost properly. (properly on 2.2 +
> patches) NFSv3 handles large files but might be missing the
> O_LARGEFILE check. I believe reiserfs went to at
> Which filesystems have limits other than 2^31 bytes?
Ext2 handles large files almost properly. (properly on 2.2 + patches)
NFSv3 handles large files but might be missing the O_LARGEFILE check.
I believe reiserfs went to at least 4Gig.
> O_LARGEFILE at present (well, their is perhaps good
> > > Add UnlockPage(page) at the end of ramfs_writepage().
> > Shit. You are quite fast. Works.
>
> Sure, especially considering the fact that patch was sent to
> Linus about a month ago (several times, actually)... ;-/
Its in all the -ac trees 8)
BTW Al: We have another general vfs/fs
Add UnlockPage(page) at the end of ramfs_writepage().
Shit. You are quite fast. Works.
Sure, especially considering the fact that patch was sent to
Linus about a month ago (several times, actually)... ;-/
Its in all the -ac trees 8)
BTW Al: We have another general vfs/fs problem
Which filesystems have limits other than 2^31 bytes?
Ext2 handles large files almost properly. (properly on 2.2 + patches)
NFSv3 handles large files but might be missing the O_LARGEFILE check.
I believe reiserfs went to at least 4Gig.
O_LARGEFILE at present (well, their is perhaps good reason
Chris Wedgwood [EMAIL PROTECTED] writes:
On Sat, Jan 06, 2001 at 03:58:20PM +, Alan Cox wrote:
Ext2 handles large files almost properly. (properly on 2.2 +
patches) NFSv3 handles large files but might be missing the
O_LARGEFILE check. I believe reiserfs went to at least
On Sat, 6 Jan 2001, Stefan Traby wrote:
> On Fri, Jan 05, 2001 at 11:52:31PM -0500, Alexander Viro wrote:
> > On Sat, 6 Jan 2001, Stefan Traby wrote:
> >
> > > Then I tried to unlink the file by running rm lfs.file log.
> > >
> > > The rm process (and an ls process that I started after that)
On Fri, Jan 05, 2001 at 11:52:31PM -0500, Alexander Viro wrote:
> On Sat, 6 Jan 2001, Stefan Traby wrote:
>
> > Then I tried to unlink the file by running rm lfs.file log.
> >
> > The rm process (and an ls process that I started after that)
> > are now in "D" state...
> >
> > root 2934
On Sat, 6 Jan 2001, Stefan Traby wrote:
> Then I tried to unlink the file by running rm lfs.file log.
>
> The rm process (and an ls process that I started after that)
> are now in "D" state...
>
> root 2934 0.0 0.2 1292 452 pts/5D05:38 0:00 ls /ramfs
> root 2952 0.0
Hi !
I create a sparse file on ramfs (by writing 5 bytes at offset 3GB):
0.000269 open("./lfs.file", O_RDWR|O_CREAT|O_TRUNC|O_LARGEFILE, 0600) = 3
0.000214 _llseek(3, 18446744072635809792, [3221225472], SEEK_SET) = 0
0.000159 write(3, "hallo", 5) = 5
Hi !
I create a sparse file on ramfs (by writing 5 bytes at offset 3GB):
0.000269 open("./lfs.file", O_RDWR|O_CREAT|O_TRUNC|O_LARGEFILE, 0600) = 3
0.000214 _llseek(3, 18446744072635809792, [3221225472], SEEK_SET) = 0
0.000159 write(3, "hallo", 5) = 5
On Sat, 6 Jan 2001, Stefan Traby wrote:
Then I tried to unlink the file by running rm lfs.file log.
The rm process (and an ls process that I started after that)
are now in "D" state...
root 2934 0.0 0.2 1292 452 pts/5D05:38 0:00 ls /ramfs
root 2952 0.0 1.5
On Fri, Jan 05, 2001 at 11:52:31PM -0500, Alexander Viro wrote:
On Sat, 6 Jan 2001, Stefan Traby wrote:
Then I tried to unlink the file by running rm lfs.file log.
The rm process (and an ls process that I started after that)
are now in "D" state...
root 2934 0.0 0.2 1292
On Sat, 6 Jan 2001, Stefan Traby wrote:
On Fri, Jan 05, 2001 at 11:52:31PM -0500, Alexander Viro wrote:
On Sat, 6 Jan 2001, Stefan Traby wrote:
Then I tried to unlink the file by running rm lfs.file log.
The rm process (and an ls process that I started after that)
are now in
99 matches
Mail list logo
