...making Linux just a little more fun!
Mahesh Aravind [ra_mahesh at yahoo.com]
Dear TAG,
I was playing around the command line (learning), and I came across df(1) reporting block size in "1k-blocks". But my dumpe2fs(8) says the block size is 4096 (4K). Shouldn't it be doing thus by default?
It seems this is filed as a Bug under Ubuntu (Bug #180415).
One suggestion is for the install program to calculate the blocksize at install time, and put it somewhere safe (immutable). Like 'export BLOCKSIZE=<whatever>' in /etc/profile.
I also saw that adding ' (apostrophe) before the block size will yield you a digit separator -- cool, eh?
I did:
BLOCKSIZE="'4096" ls -l
^ <- see this?
and it gave me size figures separated by commas! 
My $LANG is en_IN.UTF-8
YMMV
Regards,
Mahesh Aravind
Thomas Adam [thomas.adam22 at gmail.com]
2008/6/21 Mahesh Aravind <ra_mahesh@yahoo.com>:
> I did: > BLOCKSIZE="'4096" ls -l > and it gave me size figures separated by commas!
Not on my Debian Etch install it didn't. Ah well. Nice thing to know I suppose.
-- Thomas Adam
Ben Okopnik [ben at linuxgazette.net]
On Sat, Jun 21, 2008 at 04:35:56PM +0100, Thomas Adam wrote:
> 2008/6/21 Mahesh Aravind <ra_mahesh@yahoo.com>: > > I did: > > BLOCKSIZE="'4096" ls -l > > and it gave me size figures separated by commas!
Worked for me:
ben@Tyr:~$ df Filesystem 1K-blocks Used Available Use% Mounted on /dev/hda1 56214364 39826312 13532500 75% / varrun 190748 144 190604 1% /var/run varlock 190748 4 190744 1% /var/lock procbususb 190748 108 190640 1% /proc/bus/usb udev 190748 108 190640 1% /dev devshm 190748 0 190748 0% /dev/shm ben@Tyr:~$ BLOCKSIZE="'4096" df Filesystem 4K-blocks Used Available Use% Mounted on /dev/hda1 14,053,591 9,956,578 3,383,125 75% / varrun 47,687 36 47,651 1% /var/run varlock 47,687 1 47,686 1% /var/lock procbususb 47,687 27 47,660 1% /proc/bus/usb udev 47,687 27 47,660 1% /dev devshm 47,687 0 47,687 0% /dev/shm
The magic word is 'Ubuntu', I suppose. Although that seems odd, for something this basic.
-- * Ben Okopnik * Editor-in-Chief, Linux Gazette * http://LinuxGazette.NET *
Mahesh Aravind [ra_mahesh at yahoo.com]
Thomas,
> 2008/6/21 Mahesh Aravind <ra_mahesh@yahoo.com>: > > Not on my Debian Etch install it didn't. Ah well. > Nice thing to know > I suppose.
That would depend very much on your locale...
I think mine's set at LANG=en_IN.UTF-8
It's the locale that determines how the digits are to be separated. If your is "C", then no donuts for you. :D
Try something like.. LANG=en_GB.UTF-8 BLOCKSIZE="'4096" ls -l...
Hey, I also notice that the ".UTF-8" part DOES indeed makes the difference. Any idea why?
LANG=en_GB is NOT the same as LANG=en_GB.UTF-8
Wonderingly,
Mahesh Aravind
Mahesh Aravind [ra_mahesh at yahoo.com]
Ben,
> They magic word is 'Ubuntu', I suppose. Although > that seems odd, for > something this basic. >
No.. it's coreutils..
The way they handle locale, blocksize etc are different...
Trying manipulating the LANG/LC_ALL vars..
-- Mahesh Aravind
Ben Okopnik [ben at linuxgazette.net]
On Sat, Jun 21, 2008 at 10:00:02AM -0700, Mahesh Aravind wrote:
> > 2008/6/21 Thomas wrote: > > > > Not on my Debian Etch install it didn't. Ah well. > > Nice thing to know > > I suppose. > > That would depend very much on your locale... > > I think mine's set at LANG=en_IN.UTF-8 > > It's the locale that determines how the digits are to be separated. > If your is "C", then no donuts for you. :D > > Try something like.. LANG=en_GB.UTF-8 BLOCKSIZE="'4096" ls -l... > > Hey, I also notice that the ".UTF-8" part DOES indeed makes the > difference. Any idea why? > > LANG=en_GB is NOT the same as LANG=en_GB.UTF-8 > > Wonderingly, > Mahesh Aravind
It's a different charmap for that locale, thus the different result.
Different $LC_COLLATE, etc. One is configured to separate numbers that
way, the other one isn't. Frankly, I'm a bit puzzled at your puzzlement.
-- * Ben Okopnik * Editor-in-Chief, Linux Gazette * http://LinuxGazette.NET *
Mahesh Aravind [ra_mahesh at yahoo.com]
Ben,
--- On Wed, 6/25/08, Ben Okopnik <ben@linuxgazette.net> wrote:
> It's a different charmap for that locale, thus the > different result. > Different $LC_COLLATE, etc. One is configured to separate > numbers that > way, the other one isn't. Frankly, I'm a bit > puzzled at your puzzlement. >
Oh.. I didn't know that ".UTF-8" had such a profound change. But then, why isn't Thomas Adam not getting the commas?
But the purpose of this thread was to know WHY is BLOCKSIZE not set by distros. Different partioning software format the filesystem using different block sizes.
df(1), du(1) etc. automatically assumes that the disk is using 1K blocksize. Why isn't somebody doing something about it?
Regards,
Mahesh Aravind
Ben Okopnik [ben at linuxgazette.net]
On Wed, Jun 25, 2008 at 10:50:16AM -0700, Mahesh Aravind wrote:
> Ben, > > --- On Wed, 6/25/08, Ben Okopnik <ben@linuxgazette.net> wrote: > > > It's a different charmap for that locale, thus the > > different result. > > Different $LC_COLLATE, etc. One is configured to separate > > numbers that > > way, the other one isn't. Frankly, I'm a bit > > puzzled at your puzzlement. > >
Perhaps because his locale isn't set to one that uses commas to separate numbers that way?
> But the purpose of this thread was to know WHY is BLOCKSIZE not set by > distros. Different partioning software format the filesystem using > different block sizes.
I'd guess it's because it's an optional feature - not everybody wants to see their data that way, but it's available if you do.
> df(1), du(1) etc. automatically assumes that the disk is using 1K > blocksize. Why isn't somebody doing something about it?
Again, why should they? If I'm used to seeing the output of 'df' in 1k blocks, and somebody arbitrarily and suddenly changed it, I'd be pretty annoyed. Doing it the other way - i.e., sticking with what already exists and providing options to do it differently - is a) infinitely expandable and b) not likely to annoy anyone/generate help requests. It makes a lot of sense to me.
-- * Ben Okopnik * Editor-in-Chief, Linux Gazette * http://LinuxGazette.NET *