Bug#1028039: Mention "use run e2fsck -f" to fix.
The "extent tree (at level 1) could be narrower" message is overly verbose and raises concerns by end users, even though it is harmless. On the flip side, this may save only a few hundred blocks in the filesystem for a short period of time, so there is little benefit to be had by printing a message. Disable the extent optimization step in e2fsck by default by adding the "no_optimize_extents" option to e2fsck.conf. diff --git a/e2fsck.conf b/e2fsck.conf new file mode 100644 index 0..b774f9ebf --- /dev/null +++ b/e2fsck.conf @@ -0,0 +1,3 @@ +[options] +# disable extent optimization to avoid spurios "errors" during runs +no_optimize_extents=true
Bug#686447: Licence issues and non-issues with ZoL: CDDL and GPL
On Aug 29, 2014, at 4:49 AM, Carlos Alberto Lopez Perez clo...@igalia.com wrote: On 27/08/14 14:33, Carlos Alberto Lopez Perez wrote: Maybe we could share a RFC of the summary here when we think is ready, in order to double-check our understanding of the license stuff and get more feedback about it. On 27/08/14 16:38, Andreas Dilger wrote: Hi Carlos, I've been dealing with ZoL and the GPL/CDDL issues for a number of years for the Lustre filesystem. IANAL, but know quite a bit about these issues so I'd be happy to help out if I can. Thanks for the offer to help. Aron has posted our summary about the situation [1]. If you want to comment on it that would be great. In general I think this is a very well written summary of the issues. I think it is a disservice to your argument that you equate CDDL with proprietary binary licenses such as those used for NVidia or Broadcom. I would definitely seek clarification of what part of the spirit of the GPL is being violated. I think the most important point is that CDDL is an OSI-approved _open_source_ license, which eliminates IMHO the biggest objection to proprietary binary modules, since the source for ZFS is available for debugging, modification, and redistribution. The CDDL is actually a permissive license and even grants patent indemnification for any patents embodied in the original ZFS code (similar to GPLv3). It is the GPL that restricts distributing with CDDL code and not the reverse (CDDL 3.6 explicitly allows this). A little-known fact is that the CDDL even permits releasing the executable under a different license from the CDDL (CDDL 3.5). For example, it would be conceivable to distribute the module under the GPL, but that raises the question of what does a GPL license on an executable mean? Would this expose the distributor to e.g. patent license issues because it is no longer covered by the CDDL? Regards. [1] http://mid.gmane.org/20140829014229.GA9572@aron-laptop Cheers, Andreas signature.asc Description: Message signed with OpenPGP using GPGMail
Bug#686447: [zfs-discuss] Re: Licence issues and non-issues with ZoL: CDDL and GPL
On Aug 29, 2014, at 4:48 PM, Prakash Surya m...@prakashsurya.com wrote: On Fri, Aug 29, 2014 at 03:33:15PM -0600, Andreas Dilger wrote: On Aug 29, 2014, at 4:49 AM, Carlos Alberto Lopez Perez clo...@igalia.com wrote: On 27/08/14 14:33, Carlos Alberto Lopez Perez wrote: Maybe we could share a RFC of the summary here when we think is ready, in order to double-check our understanding of the license stuff and get more feedback about it. On 27/08/14 16:38, Andreas Dilger wrote: Hi Carlos, I've been dealing with ZoL and the GPL/CDDL issues for a number of years for the Lustre filesystem. IANAL, but know quite a bit about these issues so I'd be happy to help out if I can. Thanks for the offer to help. Aron has posted our summary about the situation [1]. If you want to comment on it that would be great. In general I think this is a very well written summary of the issues. I think it is a disservice to your argument that you equate CDDL with proprietary binary licenses such as those used for NVidia or Broadcom. I would definitely seek clarification of what part of the spirit of the GPL is being violated. I think the most important point is that CDDL is an OSI-approved _open_source_ license, which eliminates IMHO the biggest objection to proprietary binary modules, since the source for ZFS is available for debugging, modification, and redistribution. The CDDL is actually a permissive license and even grants patent indemnification for any patents embodied in the original ZFS code (similar to GPLv3). It is the GPL that restricts distributing with CDDL code and not the reverse (CDDL 3.6 explicitly allows this). I probably could read the GPL and figure this out, but, in what way does the GPL restrict distribution of GPL and CDDL code together? And maybe how it specifically relates to this instance, as the ZFS code is obviously not a derived work of any GPL project. You are right, and I forgot to make this important point as I was writing my first email. It is clear that ZFS is _not_ a derived work of Linux (originally written for Solaris), and Linus has himself said this in the past about AFS [1], and the GPL only covers code which is derived: If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. and just distributing them together does not change this: In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License. so if the ZoL module is not distributed as part of the kernel (i.e. in a separate package) it is no more incompatible with the GPL than any other piece of software that is available via download or on the same DVD as others. [1] http://yarchive.net/comp/linux/gpl_modules.html I try and ignore licensing issues as much as possible, but I'm curious. -- Cheers, Prakash A little-known fact is that the CDDL even permits releasing the executable under a different license from the CDDL (CDDL 3.5). For example, it would be conceivable to distribute the module under the GPL, but that raises the question of what does a GPL license on an executable mean? Would this expose the distributor to e.g. patent license issues because it is no longer covered by the CDDL? Regards. [1] http://mid.gmane.org/20140829014229.GA9572@aron-laptop Cheers, Andreas To unsubscribe from this group and stop receiving emails from it, send an email to zfs-discuss+unsubscr...@zfsonlinux.org. Cheers, Andreas signature.asc Description: Message signed with OpenPGP using GPGMail
Bug#738758: [PATCH] ext4: kill i_version support for Hurd-castrated file systems
Probably worthwhile to make those !EXT4_OS_HURD checks likely()?
Cheers, Andreas
On Mar 19, 2014, at 22:34, Theodore Ts'o ty...@mit.edu wrote:
The Hurd file system uses uses the inode field which is now used for
i_version for its translator block. This means that ext2 file systems
that are formatted for GNU Hurd can't be used to support NFSv4. Given
that Hurd file systems don't support extents, and a huge number of
modern file system features, this is no great loss.
If we don't do this, the attempt to update the i_version field will
stomp over the translator block field, which will cause file system
corruption for Hurd file systems. This can be replicated via:
mke2fs -t ext2 -o hurd /dev/vdc
mount -t ext4 /dev/vdc /vdc
touch /vdc/bug
umount /dev/vdc
e2fsck -f /dev/vdc
Addresses-Debian-Bug: #738758
Reported-By: Gabriele Giacone 1o5g4...@gmail.com
Signed-off-by: Theodore Ts'o ty...@mit.edu
---
fs/ext4/inode.c | 29 ++---
1 file changed, 18 insertions(+), 11 deletions(-)
diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
index 7cc2455..ed2c13a 100644
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -4168,11 +4168,14 @@ struct inode *ext4_iget(struct super_block *sb,
unsigned long ino)
EXT4_INODE_GET_XTIME(i_atime, inode, raw_inode);
EXT4_EINODE_GET_XTIME(i_crtime, ei, raw_inode);
-inode-i_version = le32_to_cpu(raw_inode-i_disk_version);
-if (EXT4_INODE_SIZE(inode-i_sb) EXT4_GOOD_OLD_INODE_SIZE) {
-if (EXT4_FITS_IN_INODE(raw_inode, ei, i_version_hi))
-inode-i_version |=
-(__u64)(le32_to_cpu(raw_inode-i_version_hi)) 32;
+if (EXT4_SB(inode-i_sb)-s_es-s_creator_os !=
+cpu_to_le32(EXT4_OS_HURD)) {
+inode-i_version = le32_to_cpu(raw_inode-i_disk_version);
+if (EXT4_INODE_SIZE(inode-i_sb) EXT4_GOOD_OLD_INODE_SIZE) {
+if (EXT4_FITS_IN_INODE(raw_inode, ei, i_version_hi))
+inode-i_version |=
+(__u64)(le32_to_cpu(raw_inode-i_version_hi)) 32;
+}
}
ret = 0;
@@ -4388,12 +4391,16 @@ static int ext4_do_update_inode(handle_t *handle,
raw_inode-i_block[block] = ei-i_data[block];
}
-raw_inode-i_disk_version = cpu_to_le32(inode-i_version);
-if (ei-i_extra_isize) {
-if (EXT4_FITS_IN_INODE(raw_inode, ei, i_version_hi))
-raw_inode-i_version_hi =
-cpu_to_le32(inode-i_version 32);
-raw_inode-i_extra_isize = cpu_to_le16(ei-i_extra_isize);
+if (EXT4_SB(inode-i_sb)-s_es-s_creator_os !=
+cpu_to_le32(EXT4_OS_HURD)) {
+raw_inode-i_disk_version = cpu_to_le32(inode-i_version);
+if (ei-i_extra_isize) {
+if (EXT4_FITS_IN_INODE(raw_inode, ei, i_version_hi))
+raw_inode-i_version_hi =
+cpu_to_le32(inode-i_version 32);
+raw_inode-i_extra_isize =
+cpu_to_le16(ei-i_extra_isize);
+}
}
ext4_inode_csum_set(inode, raw_inode, ei);
--
1.9.0
--
To unsubscribe from this list: send the line unsubscribe linux-ext4 in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#660781: mlocate /etc/updatedb.conf should exclude fstype lustre
Package: mlocate Version: 0.23.1-1 The mlocate package currently excludes the lustre_lite filesystem type in its /etc/updatedb.conf file: PRUNEFS=NFS nfs nfs4 rpc_pipefs afs binfmt_misc proc smbfs autofs iso9660 ncpfs coda devpts ftpfs devfs mfs shfs sysfs cifs lustre_lite tmpfs usbfs udf fuse.glusterfs fuse.sshfs However, this hasn't been the filesystem type for Lustre for many years, only on ancient 2.4 kernels. All 2.6 kernels have used lustre as the fstype. I don't currently have any Debian-based systems, but this problem was sent to me by a Lustre user, and is still present in the latest version of updatedb.conf available from Git. Since there is no updatedb.conf in the upstream mlocate package, this update needs to be made in all of the distros separately. The Fedora 12 mlocate updatedb.conf has already been updated similarly. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#660781: [PATCH] Exclude lustre filesystem type (Closes: #660781)
--- debian/updatedb.conf |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/debian/updatedb.conf b/debian/updatedb.conf index f733293..20afadf 100644 --- a/debian/updatedb.conf +++ b/debian/updatedb.conf @@ -1,4 +1,4 @@ PRUNE_BIND_MOUNTS=yes # PRUNENAMES=.git .bzr .hg .svn PRUNEPATHS=/tmp /var/spool /media -PRUNEFS=NFS nfs nfs4 rpc_pipefs afs binfmt_misc proc smbfs autofs iso9660 ncpfs coda devpts ftpfs devfs mfs shfs sysfs cifs lustre_lite tmpfs usbfs udf fuse.glusterfs fuse.sshfs +PRUNEFS=NFS nfs nfs4 rpc_pipefs afs binfmt_misc proc smbfs autofs iso9660 ncpfs coda devpts ftpfs devfs mfs shfs sysfs cifs lustre tmpfs usbfs udf fuse.glusterfs fuse.sshfs -- 1.7.2 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#188663: [Bug-tar] tar fails to preserve hard links with --remove-files
On Jul 30, 2009 04:57 -0700, Carl Worth wrote: On Sun, 13 Apr 2003 15:45:27 -0400, Theodore Ts'o ty...@mit.edu wrote: I'm pretty sure, by the way, that the problem is that tar is keying off of the st_nlink to decide whether or not to do hard link processing as an optimization. When --remove-files is present, then st_nlink of the hard-linked inode is dropping, and when st_nlink is one, tar can't tell that it was previously a hard-linked file. The fix would require that tar check every single file's inode number against previously written files to see if it was a hard linked file (instead of just checking files where st_nlink 1), in the case when --remove-file option is in use. I've attached two patches to fix this bug. The first implements Ted's suggestion, (using the hard links hash table for all files when the --remove-files option is in effect, regardless of the value of st_nlink). The second patch adds a test case for the bug, (failing before the first patch is added and passing afterwards). Rather than do a lookup of every file in the filesystem in the hard link table ($num_files lookups in the hash table) it would probably be more efficient to save the second-last link to the file, mark the hash table entry with delete on next link, and when the last link is found unlink both of them at once. That would avoid hash lookups for 99% of the files in the archive (if assuming typical hard link ratios). Cheers, Andreas -- Andreas Dilger Sr. Staff Engineer, Lustre Group Sun Microsystems of Canada, Inc. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#295755: (no subject)
-- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#295755: (no subject)
-- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#295755: (no subject)
-- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#295755: module-init-tools: reads user's backup files in /etc/modprobe.d
I recently ran into the problem of modprobe trying to read backup files from /etc/modprobe.d, and because of sorting (I guess) it was always using the old (backup) settings instead of the settings in the original file, as in: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=295755 Modprobe started spitting out strange error messages after I had changed a module parameter. I tried reverted the change and otherwise debug the problem by going back to the orignal settings. Of course, even deleting the backup file and then re-editing the base file to try another combination of settings ended up with a continuous cascade of on-again/off-again errors. This was preventing my headless MythTV system from starting up correctly and was not very fun to debug - I only noticed some months after I had changed the original setting and did not reboot. The backup file was created by vim with the .orig extension in the /etc/modprobe.d directory, but I'd imagine similar problems would be had with emacs and ~ extension files. I'm using KnoppMyth R5E50 with the 3.3-pre3-1 module-init-tools (Debian 4.0). Cheers, Andreas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#389772: e2fsprogs: e2fsck produces broken htree on ppc
On Sep 28, 2006 21:08 -0400, Theodore Tso wrote: On Wed, Sep 27, 2006 at 02:22:51PM +0200, Jörg Sommer wrote: Package: e2fsprogs Version: 1.39-1 Severity: important you set the compiler option -fsigned-char, but on PowerPC the default is unsigned char. This makes the kernel uses unsigned and e2fsck uses signed chars. In the case of an 8 bit character, str2hashbuf() in lib/ext2fs/dirhash.c produces a different buf than the kernel, which leads to the problem that the hash calculated by TEA_transform() is a different one. Oh, dear. This is actually a kernel bug, because the on all other platforms, the TEA hash will be using a signed char --- and if you want filesystems to be portable between different systems (hint: we do), then all architectures should be using the same algorithm. And the vast majority of the systems out there are using signed chars. Unfortunately PowerPC decided to be different. :-( But given that e2fsck is doing it right, and the kernel is doing it wrong, we have the mismatch already. Sigh, this is going to be especially painful, given that all the major distributions (SLES, RHEL, Debian, Ubuntu, etc.) are now shipping with directory hashing enabled by default, and so this is going to impact a huge number of PowerPC Linux users and customers. Hmm, except isn't the problem ALREADY that PPC is broken with 8-bit chars and htree? That's what started this problem in the first place. Running e2fsck allowed the kernel htree code to find the file, when it could not otherwise be looked up... Need to verify that (my mental stack is overflowing). IIRC this problem was also reported in the past but no solution was found. I think fixing the kernel to specify signed chars for the hash will FIX the PPC kernel code. Cheers, Andreas -- Andreas Dilger Principal Software Engineer Cluster File Systems, Inc.
Bug#388452: e2fsprogs: Please conside the attached patches, used for lustre filesystems
On Sep 21, 2006 07:55 -0400, Theodore Tso wrote: On Wed, Sep 20, 2006 at 02:37:17PM +0100, Alastair McKinstry wrote: Attached are some patches used by Lustre; the patches are written by cluster filesystems, inc. and are apparently expected to be in the next release of e2fsprogs upstream, 1.40. Lustre is a cluster filesystem that uses a modified ext3 fs underneath; including additional ext3 attributes not supported by standard ext3. For lustre you use this modified e2fsck. 1) These patches will not enter e2fsprogs upstream with some significant changes, which I am currently working on, and 2) These patches are not enough to enable e2fsprogs check Lustre filesystems. Clusterfs maintains their own set of changes that goes beyond this set of patches. These patches are designed to get the Lustre tree closer in sync with e2fsprogs, but is not sufficient for e2fsprogs to check Lustre filesystems. To clarify: - many of these patches have already been accepted upstream - it is not absolutely required to have the CFS-patched e2fsprogs, IF the Lustre OST filesystems are not using the extents feature - the extents support that is expected to be in e2fsprogs-1.40 will work with the lustre extents patches, which is the only incompatible on-disk format change used by lustre - the lfsck tool (which is one of the few CFS patches that has not been submitted upstream yet) is not required in order for e2fsck to work with a Lustre filesystem. If the individual ext3 filesystems are internally consistent (i.e. e2fsck completed, in case of corruption) then Lustre itself will still work in the face of inter-filesystem inconsistencies (i.e. objects missing/extra on OSTs compared to MDS filesystem), possibly with EIO or ENOENT errors returned to applications or leakage of space on the OST filesystems. I would of course be happy to get as many patches into the upstream e2fsprogs package. Cheers, Andreas -- Andreas Dilger Principal Software Engineer Cluster File Systems, Inc. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#388452: (no subject)
-- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#281589: [ext2resize] [PATCH] to build ext2resize-1.1.19 against modern asm/ioctl.h
On Jan 12, 2005 14:47 +, Alex Owen wrote: I believe there is a bug in the definition of BLKGETSIZE64 in ext2resize-1.1.19/src/ext2_unix_io.c I believe that this patch fixes the problem: ---8--- --- ext2resize-1.1.19/src/ext2_unix_io.c2004-09-30 15:04:04.0 +0100 +++ ext2resize-1.1.19.works/src/ext2_unix_io.c 2005-01-11 17:56:14.0 + @@ -47,7 +47,7 @@ #endif #ifndef BLKGETSIZE64 -#define BLKGETSIZE64 _IOR(0x12,114,sizeof(unsigned long long)) +#define BLKGETSIZE64 _IOR(0x12,114,unsigned long long) #endif struct my_cookie Thanks, I've committed this change to CVS. Cheers, Andreas -- Andreas Dilger http://sourceforge.net/projects/ext2resize/ http://members.shaw.ca/adilger/ http://members.shaw.ca/golinux/ pgplzaOppuVMQ.pgp Description: PGP signature
