linux-kernel - Re: [RFC/PATCH] - revert generic_fillattr stat->blksize to PAGE_CACHE

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 07 Nov 2006 07:40:45 -0600
From:	Dave Kleikamp <shaggy@...ux.vnet.ibm.com>
To:	Steve French <smfltc@...ibm.com>
Cc:	Eric Sandeen <sandeen@...hat.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>,
	Theodore Tso <tytso@....edu>
Subject: Re: [RFC/PATCH] - revert generic_fillattr stat->blksize to	 
	PAGE_CACHE_SIZE

On Mon, 2006-11-06 at 18:26 -0600, Steve French wrote:   
> I assumed that the original intent of the "inode diet patch" was to 
> remove fields in the inode,
> which most filesystems can get out of the superblock. 

I think I may have planted the idea that you could get i_blkbits from
sb->s_blocksize_bits, but I was wrong.  Consider a block device.  It's
blocksize is not related to the superblock of its containing filesystem.

>    If 
> inode->blksize and inode->blkbits were
> related (2**blkbits == blksize) , it also makes sense to me that someone 
> (Ted?) removed one and left the other
> as one would be redundant,

They were never really related.  Some filesystems treated them as if
they were, but the vfs always used i_blkbits for the block size.
i_blksize was only really used for returning stat->blksize.

>  but some filesystems like cifs have a large 
> recommended i/o size (16K),
> but if someone wants to remove both from the inode that is fine by me, 
> as long as cifs
> stat->blksize is set as you suggested on the way out of cifs_getattr.    
> Eventually cifs should set
> the stat->blksize to  a smaller value for one rarer case.   For the most 
> common case
> cifs should still set it to 16K (CIFS_MAX_MSGSIZE) as that is the most 
> common negotiated
> buffer size but if the server does not negotiate large read support, and 
> the server also is so old
> that it negotiates a buffer size smaller than 16K (e.g. Windows95 
> negotiates 2K IIRC)
> then we could set stat-blksize to the smaller negotiated buffer size - 
> but since those servers are
> getting rarer it is probably not that important.    More interesting 
> will be the future cases in
> which we will be able to set this value larger to more servers, as in 
> general for modern
> network adapters, the larger network i/o size the better.

It would probably be best to just set stat->blksize to the negotiated
buffer size.
-- 
David Kleikamp
IBM Linux Technology Center

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/