[lkml]   [2005]   [Dec]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] fs: remove s_old_blocksize from struct super_block

On Sat, 3 Dec 2005, Pekka Enberg wrote:
> On Fri, 2 Dec 2005, Pekka Enberg wrote:
> > > The s_old_blocksize field of struct super_block is only used as a temporary
> > > variable in get_sb_bdev(). This patch changes the function to use a local
> > > variable instead so we can kill the field from struct super_block.
> On Sat, 2005-12-03 at 11:02 +0000, Anton Altaparmakov wrote:
> > s_old_blocksize used to be used to restore the blocksize after the
> > filesystem had failed to mount or had unmounted. Not restoring this leads
> > to all sorts of problems since the blocksize may be set for example to 4k
> > but some userspace app may need it to be set to 1k or whatever. There
> > used to be applications that failed which is why s_old_blocksize was
> > introduced and it used to restore the blocksize.
> >
> > I have no idea why/when the restoring has been removed but chances are the
> > removal was wrong. Now every file system will need to restore the
> > blocksize itself (as it used to be before s_old_blocksize and blocksize
> > restoral was introduced). Except whoever removed the restoration failed
> > to fix up all file systems. )-:
> It was removed in this commit, I think:

Yes, it certainly was removed there. Thanks for finding the commit. That
had gone past me unnoticed.

This means we are now back to the old behaviour where fs utilities will
behave randomly/unpredictably depending on what fs was mounted (or even
was tried to be mounted!) on the device last. So for example a failing
"mount -t auto" will leave the block size set to a random number when all
fs utilities (at least used to) asume the block size is 1k and strangeness

I have no idea why Jeff (Mahoney) considered the setting to be
unnecessary, when Al Viro added the resetting code a few years ago it
was done precisely because utilities were behaving randomly/erratically...

IMHO the above commit consitutes a regression in 2.6 kernel.

Best regards,

Anton Altaparmakov <aia21 at> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer / IRC: #ntfs on
WWW: &
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-12-03 15:37    [W:0.264 / U:0.108 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site