Well, anyway, the original intent was to reclaim some of the space lost to file "tails" by using a smaller blocksize, but it sounds like we'd lose more than we'd gain.
Mike was asking about this on our behalf. We had noticed that we weren't getting as much space using ext3 as we had with reiser. Most of this turned out to be due to the "reserved blocks", which defaults to 5% on ext3, but the issue of file tails came up in the discussion. Reiser has a feature which reduces overhead caused by this. Reducing block size to 1k for ext3 filesystems with many small files seemed like a possible solution. > -----Original Message----- > From: Linux on 390 Port [mailto:[EMAIL PROTECTED] Behalf Of > McKown, John > Sent: Wednesday, February 18, 2004 12:54 PM > To: [EMAIL PROTECTED] > Subject: Re: [LINUX-390] dasdfmt with a 1K block size - still not > recommde d? > > > > -----Original Message----- > > From: Richard Troth [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, February 18, 2004 11:48 AM > > To: [EMAIL PROTECTED] > > Subject: Re: dasdfmt with a 1K block size - still not recommde d? > > > > > > > Why would it not fill the track? > > > > <snip> > > > Real 3390 DASD are the same in this aspect. The magnetic markers > > between blocks (records) are the same size regardless of the size > > of the blocks themselves. Smaller blocks, same inter-block gaps. > > Dunno why it would be strictly true for contemporary "3390" > which are > > emulated by 512-byte FBA critters under the covers, > > except perhaps to be true to the emulation. > > > > -- R; > > From what I understand, there are not any "real" IBGs on the > emulated DASD. > However, MVS and its successors "know" how 3390 track > geometry is supposed > to work. So the emulated DASD controller must emulate the > "overhead" so that > "too much" data does not go onto an emulated track. Things > like TRKCALC and > other access methods depend on an emulated track only getting > "x" blocks on > a single track when the blocksize is "n". If it got "x+?" > where ?!=0, the > access method would likely malfunction. Perhaps missing > records when doing > addressed (to a specific cylinder, head, record) when it > tried to calculate > this address from a "relative block" number. > > > -- > John McKown > Senior Systems Programmer > UICI Insurance Center > Applications & Solutions Team > > This message (including any attachments) contains > confidential information > intended for a specific individual and purpose, and its' content is > protected by law. If you are not the intended recipient, you > should delete > this message and are hereby notified that any disclosure, copying, or > distribution of this transmission, or taking any action based > on it, is > strictly prohibited. > ============================================================================== If you are not an intended recipient of this e-mail, please notify the sender, delete it and do not read, act upon, print, disclose, copy, retain or redistribute it. Click here for important additional terms relating to this e-mail. <http://www.ml.com/email_terms/> ==============================================================================
