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>] [day] [month] [year] [list]
Date:	Wed, 17 Jan 2007 17:29:47 -0800
From:	"AVANTIKA R. MATHUR" <mathur@...ux.vnet.ibm.com>
To:	linux-ext4@...r.kernel.org
Subject: Ext4 devel interlock meeting minutes (Jan. 17 2007)

Ext4 Developer Interlock Call
Meeting Minutes January 17, 2007

Attendees: Mingming Cao, Dave Kleikamp, Jean Pierre Dion, Jean Noel 
Cordenner, Valerie Clement, Suparna Bhattacharya, Eric Sandeen, Avantika 
Mathur

- In the last call Ted proposed having a git tree for ext4 on 
kernel.org, and Mingming then sent an email to the list requesting 
everyone to resend latest versions of ext4 patches to put in these 
tree.  Mingming suggested that all bug fixes to ext4 should also be 
copied to the git tree

- Eric asked if people would be interested if ext4 built better as 
module.  First by perhaps moving some ext4 headers from include/linux to 
the ext4 directory; making it easier to build as a module

- Takashi posted updated patches to the mailing list. Mingming update 
the ext4 wiki with status. Andreas and Takashi have been discussing what 
the interface for online defragmentation should be.  The next step is to 
wait for a new patch set from Takashi, as there are some to do items.

- Preallocation: Amit Arora posted new patch set, Mingming reviewed the 
patches and they look good.
   -- The main outstanding issue is determining what the interface 
should be: ioctl, fcntl, ftruncate, posix_fallocate.    -- Eric does not 
want to use ftruncate as it does not support creating sparse files.
   -- Mingming asked if the return value should be how many blocks were 
allocated, because when allocating accross holes, it may not allocate 
number of blocks requested.  Eric did not see allocation accross holes 
to be a common case, and was not sure if the number of blocks allocated 
will be useful.  Eric will check how XFS handles this situation, it 
could be helpful to try to keep semantics similar accross filesystems.

- Support for trillions of files in ext4: Mingming asked how XFS handles 
a 64 bit inode number and binary incompatability issues.
   -- XFS by default limits the inode number to 32 bit range; but can be 
configured for 64 bit inode numbers.  Eric suggested that as a 
filesystem that is moving forward, ext4 could default to 64 bit inodes, 
but be set to 32 bit inode if necesary.
   -- Eric also mentioned looking at the scaling of mkfs block/inode 
ratio based on filesystem size
   -- fsck time on very large number of files is also an issue

- Mingming discussed the limitation on filesystem size by the fact that 
all block group descriptors are stored in the first block; this limits 
max filesystem size to 256 TB.  We could enlarge the block group size to 
store more block group descriptors or not store all descriptors in the 
same block group. If meta block groups are turned on by default, this 
limit could be resolved, but all peices for this feature may not be in 
place.

- Encourage developers to update the ext4 wiki (ext4.wiki.kernel.org), 
new patches page with details and status on features, It might be 
helpful if there is a separate page on the WIKI for each feature.

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

Powered by blists - more mailing lists