[Nexus 7 Q&A, Help & Troubleshooting] bftb0:
Could be, but then the Google factory images do not discriminate between 8/16/32, and in this case the OP used a factory image.

@Zsded

I had this happen to me the other night (in the middle of doing something else). The long & boring story follows, but let's begin with a solution: The partitioning data did not get changed, but mysteriously the /data filesystem got created with with only about 6-7 GB of capacity. Re-creating the /data filesystem using the "Format data" operation in TWRP will create an ext4 filesystem of 29 GB or so.

You need to backup everything worth saving and re-create the /data filesystem. This can be accomplished (for instance) using the "Format data" operation in TWRP. But - again - this destroys everything in /data including everything in /sdcard. (Note it does not touch /system or /cache though - so your bare ROM is still there)

What you might want to do is the following:

1) back up everything in /sdcard that you want to save

2) make a full Nandroid backup of your current ROM

3) get copies of the TWRP Nandroid backup off the device (on to the PC)

4) perform the "format data" operation in TWRP (iirc it is in the Wipe sub-menu)

5) copy your Nandroid backup back to the tablet***

6) restore the Nandroid backup (or just the data partition if you prefer)

7) Boot into the ROM and copy the saved contents of /sdcard back onto your device from your PC

*** This is a mouthful. On a fresh /data filesystem, TWRP (v2.4.1.0, anyway) wants to find its backup folders at

/data/media/TWRP/BACKUPS/<device-id>/*

But if you use MTP with the OS to copy the nandroid backup files, you will only have access to /data/media/0/* (the "sdcard" mount point) using MTP So, you might need to copy the files and then using a root shell or the custom recovery, get a copy of your TWRP folder into /data/media/ e.g. with TWRP recovery booted:

adb shell cp -R /data/media/0/TWRP/ /data/media/

OK, now for the long and boring story.

I had something identical happen to me the other night - I have a 32G N7, and it ended up showing only 6.5 GB total in /data. Because of the sequence of events involved, I don't know the exact cause, but using TWRP to re-create the /data filesystem as explained above solved the problem.

First, some background so you will know why I don't know the cause (get a beverage, this is going to be a long post):

The other night, I decided to capture Nandroid backups of every N7 factory ROM from JZO54K through JDQ39 (4.1.2 - 4.2 - 4.2.1 - 4.2.2). My plan was to do a factory install of JZ054K (4.1.2) and then apply each of the OTAs in sequence. So, I backed everything up (including using a certain busybox version of "tar" to backup about 2.5 Gigs of stuff from the /sdcard mount point), and completely wiped the device and did a fastboot install of 4.1.2 (JZO54K) nakasi (WiFi N7) factory ROM.

The ony thing that I did not do in the initial step was flash the bootloader - I left the 4.18 bootloader in place (initially). I did not follow the factory install script; instead I used the following sequence:

fastboot erase boot
fastboot erase recovery
fastboot erase system
fastboot erase userdata
fastboot erase cache

fastboot flash boot boot.img
fastboot flash recovery recovery.img

fastboot format system
fastboot format userdata
fastboot format cache

fastboot flash system system.img
fastboot flash userdata userdata.img

The above installed the JZO54K factory ROM - but with the newer 4.18 bootloader still in place.

For each of the OTA package installs & nandroid backups, I would "soft-boot" TWRP (thus leaving the factory recovery still flashed on the tablet), e.g.:

C:\foo> fastboot boot openrecovery-twrp-2.4.1.0-grouper.img
C:\foo> adb push 094f6629314a.signed-nakasi-JOP40C-from-JZO54K.094f6629.zip /cache/update.zip
C:\foo> adb shell sha1sum /cache/update.zip
C:\foo> adb shell
# cd /cache/recovery
# echo '--update_package=/cache/update.zip' > command
# exit
C:\foo> adb reboot recovery
... (OTA runs, device reboots into OS, perform shutdown, boot to bootloader) ...
C:\foo> fastboot boot openrecovery-twrp-2.4.1.0-grouper.img
... take a Nandroid backup (including recovery partition!)...

Now, as it turned out, before any of this had taken place I had noticed filesystem corruption in my /system partition. Because I was making Nandroid backups for reference/archival purposes, after each OTA install, just prior to making the nandroid backup (with TWRP soft-booted as shown above), I did a filesystem check on system and data:

adb shell e2fsck -f -n /dev/block/mmcblk0p3
adb shell e2fsck -f -n /dev/block/mmcblk0p9

(for Wifi/nakasi/grouper devices, mmcblk0p3 is /system and mmcblk0p9 is /data).

The reason I mention this is that I was focused on making sure that there were no filesystem errors (there were none). Had I been paying attention, I might have noticed that something was wrong with the allocation size. But, read on...

When I finally got finished (3 OTAs and 3 Nandroid backups) I decided to restore the contents of my 2.5 Gb tarball. Nothing should been in /data except for a couple (TWRP) Nandroid backups. So, I start restoring the tarball... and after a good long wait ... tar exits due to lack of space. WTF?

Well, /data and /sdcard were mounted (in TWRP), so I did a

adb shell df -k /data

and it showed a little over 4.5 GB used ... in a 6.5 GB partition - WTF?

Now, because I wasn't watching carefully, I can't be sure what caused the small filesystem in a big partition, but here's my theory:

Because the OTAs are designed to leave /data and /data/media/* alone (more or less), that means that the /data filesystem was only created once: it would not have been destroyed & re-created by the successive application of the 3 OTA bundles that took me from JZ054K -> JOP40C -> JOP40D -> JDQ39.

To me, that says that one of the two following initial operations was the culprit:

fastboot erase userdata
fastboot format userdata

OR

fastboot flash userdata userdata.img

What is rather shocking about this is because of the way that I did things, I had the newest bootloader on the device when I did this - v4.18. I wouldn't have been surprised if an older bootloader had a bug that got fixed... but it surprises me that the very newest bootloader seems to be implicated.

But anyway - to recap - your partition data has not been altered. AFAIK, nobody (but Asus/Google) knows how to do that as it probably requires talking to the device in APX mode. Somehow, whatever recreated your filesystem in /dev/block/platform/sdhci-tegra.3/by-name/UDA ( userdata ) mysteriously created a filesystem substantially smaller than the physical partition size.

My suspicion is that it is a bug in the bootloader.

good luck