linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Vladimir 'φ-coder/phcoder' Serbinenko" <phcoder@gmail.com>
To: linux-fsdevel@vger.kernel.org
Subject: Fwd: [PATCH] UFS i_blocks handling
Date: Thu, 10 May 2012 00:01:22 +0200	[thread overview]
Message-ID: <4FAAE932.70007@gmail.com> (raw)
In-Reply-To: <4FA1620A.3040700@gmail.com>


[-- Attachment #1.1: Type: text/plain, Size: 943 bytes --]

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 <phcoder@gmail.com>
To: 	linux-kernel@vger.kernel.org



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.

-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko




[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: ufs.diff --]
[-- Type: text/x-diff; name="ufs.diff", Size: 767 bytes --]

diff -ur linux-source-3.2/fs/ufs/balloc.c /home/phcoder/projects/ufs/balloc.c
--- linux-source-3.2/fs/ufs/balloc.c	2012-04-23 00:31:32.000000000 +0200
+++ /home/phcoder/projects/ufs/balloc.c	2012-05-02 18:24:25.444822068 +0200
@@ -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,


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 294 bytes --]

           reply	other threads:[~2012-05-09 22:01 UTC|newest]

Thread overview: expand[flat|nested]  mbox.gz  Atom feed
 [parent not found: <4FA1620A.3040700@gmail.com>]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4FAAE932.70007@gmail.com \
    --to=phcoder@gmail.com \
    --cc=linux-fsdevel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).