Skip to contentSkip to conversation

UFS i_blocks handling

PATCH New Vladimir 'φ-coder/phcoder' Serbinenko 1 participant 2 messages May 2, 2012 – May 9, 2012 VFS

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 UFS i_blocks handling

Current UFS code doesn't maintain i_blocks. It creates 2 glitches:
1) state always says that no blocks are allocated
2) long symlinks are corrupted.
For (2) in GRUB there is a workaround to check whether link is a fast link based on its length (link is considered a fast one if its size is small to fit in inline space and i_blocks == 0) however neither Linux nor BSD-using OS have such workaround and this should be fixed anyway. Please consider attached patch. It may be of bad quality, I haven't learned the code in question in more details.
Please CC me when answering.

Signature · 2 lines
Regards
Vladimir 'φ-coder/phcoder' Serbinenko
home/phcoder/projects/ufs/balloc.c renamed from fs/ufs/balloc.c +3 -0
diff -ur linux-source-3.2/fs/ufs/balloc.c /home/phcoder/projects/ufs/balloc.c
@@ -147,6 +147,8 @@
 
 	UFSD("ENTER, fragment %llu, count %u\n",
 	     (unsigned long long)fragment, count);
+
+	inode->i_blocks -= count;
 	
 	if ((fragment & uspi->s_fpbmask) || (count & uspi->s_fpbmask)) {
 		ufs_error (sb, "ufs_free_blocks", "internal error, "
@@ -423,6 +425,7 @@
 		if (result) {
 			ufs_cpu_to_data_ptr(sb, p, result);
 			*err = 0;
+			inode->i_blocks += count;
 			UFS_I(inode)->i_lastfrag =
 				max(UFS_I(inode)->i_lastfrag, fragment + count);
 			ufs_clear_frags(inode, result + oldcount,
#1 lore raw

PATCH 1/1 UFS i_blocks handling

Since it was ignored on LKML, I guess this should be the right list.

-------- Original Message --------
Subject: [PATCH] UFS i_blocks handling
Date: Wed, 02 May 2012 18:34:18 +0200
From: Vladimir 'φ-coder/phcoder' Serbinenko <[email protected]>
To: [email protected]

Current UFS code doesn't maintain i_blocks. It creates 2 glitches:
1) state always says that no blocks are allocated
2) long symlinks are corrupted.
For (2) in GRUB there is a workaround to check whether link is a fast link based on its length (link is considered a fast one if its size is small to fit in inline space and i_blocks == 0) however neither Linux nor BSD-using OS have such workaround and this should be fixed anyway. Please consider attached patch. It may be of bad quality, I haven't learned the code in question in more details.
Please CC me when answering.

Signature · 2 lines
Regards
Vladimir 'φ-coder/phcoder' Serbinenko
home/phcoder/projects/ufs/balloc.c renamed from fs/ufs/balloc.c +3 -0
diff -ur linux-source-3.2/fs/ufs/balloc.c /home/phcoder/projects/ufs/balloc.c
@@ -147,6 +147,8 @@
 
 	UFSD("ENTER, fragment %llu, count %u\n",
 	     (unsigned long long)fragment, count);
+
+	inode->i_blocks -= count;
 	
 	if ((fragment & uspi->s_fpbmask) || (count & uspi->s_fpbmask)) {
 		ufs_error (sb, "ufs_free_blocks", "internal error, "
@@ -423,6 +425,7 @@
 		if (result) {
 			ufs_cpu_to_data_ptr(sb, p, result);
 			*err = 0;
+			inode->i_blocks += count;
 			UFS_I(inode)->i_lastfrag =
 				max(UFS_I(inode)->i_lastfrag, fragment + count);
 			ufs_clear_frags(inode, result + oldcount,